安全补丁SUPEE-11086-可能的问题?


24

Magento发布了针对M1的新安全补丁,以及针对M1和M2的更新。

这些版本包含重要的安全修复程序。“我们强烈建议所有商家尽快升级。”

升级或应用此补丁时应注意哪些问题?

SUPEE-11086

SUPEE-11086,Magento Commerce 1.14.4.1和开源1.9.4.1包含多项安全增强功能,可帮助关闭远程代码执行(RCE),跨站点脚本(XSS),跨站点请求伪造(CSRF)和其他漏洞。

Magento 2.3.1、2.2.8和2.1.17安全更新

这些版本包含多个功能和安全更新。风险:对于2.1.17、2.2.8和2.3.1之前的Magento Commerce和Magento开源至关重要。


Ryan Hoerr,我想您必须为Magento 2.3.1、2.2.8和2.1.17创建一个不同的问题。安全更新
Amit Bera

2
知道为什么没有1.8.0 / 1.8.1的版本吗?
杰森(Jason)

Answers:


20

发现的最大问题: Mage::log()工作不正常。如果您使用自定义日志文件调用此函数(并且尚不存在),则由于SUPEE-11086中添加了其他验证,因此日志不会写入该文件。


此问题也适用于Magento的CE 1.9.4.1:magento.stackexchange.com/questions/268229/...
阿德Mathijssen

5
我所有的日志都完全停止了。甚至系统日志和异常日志。有解决办法吗?
Kalvin Klien

我所有由Mage :: log写入的日志文件也都停止了。M1 EE 1.14.0.2
PromInc

唯一的解决方法是返回Mage::log()
Aswerer

3
自6月25日起,Magento已发布SUPEE-11155,Magento Commerce 1.14.4.2和Magento Open Source 1.9.4.2,其中包括该Mage::log()方法的修复程序。
Aad Mathijssen


5

和其他人一样,我的日志文件完全停止写入数据。

错误的来源-日志文件未写入数据

app/Mage.php他们作出这个改变:

         // Validate file extension before save. Allowed file extensions: log, txt, html, csv
         -        if (!self::helper('log')->isLogFileExtensionValid($file)) {
         +        $_allowedFileExtensions = explode(
         +            ',',
         +            (string) self::getConfig()->getNode('dev/log/allowedFileExtensions', Mage_Core_Model_Store::DEFAULT_CODE)
         +        );
         +        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         +        $logDir = self::getBaseDir('var') . DS . 'log';
         +        if (!$logValidator->isValid($logDir . DS . $file)) {
                 return;
             }

它正在配置中查找以逗号分隔的已批准文件扩展名列表。他们没有在配置中添加此列表,但是-在Mage Admin中甚至没有一个选项供我们自行配置。

错误的解决方案-日志文件未写入数据

要解决此问题,只需在core_config_data表中的数据库中进行输入。

INSERT INTO core_config_data VALUES ( NULL, 'default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv' );

同时清除对象缓存,您应该再次看到数据写入日志文件。

ls -lrt var/log/ | tail


作为参考,此问题是在EE 1.14.2.0上应用的所有安全修补程序。

我确实已就此问题向Magento支持人员开了票,但尚未收到技术人员的答复。我在排队。


这个错误真正让我感到困惑的是,Magento已经拥有一种方法来验证他们在2017年末通过SUPEE-10415添加的日志文件扩展名。

app/code/core/Mage/Log/Helper/Data.php

    /**
     * Checking if file extensions is allowed. If passed then return true.
     *
     * @param $file
     * @return bool
     */
    public function isLogFileExtensionValid($file)
    {
        $result = false;
        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
        if ($validatedFileExtension && in_array($validatedFileExtension, $this->_allowedFileExtensions)) {
            $result = true;
        }

        return $result;
    }

他们为什么不重用这种逻辑,而不是尝试对日志轮进行不完全的重新发明?


3
这是不正确的。在app / etc / config.xml中,allowedFileExtensions已作为配置添加。如果它在数据库中不存在,将使用它。实际的问题是,新的验证功能首先尝试查看该文件是否已经存在,而它可能非常不存在。
勒内Schep

感谢您指出@RenéSchep,我现在看到补丁中的更改。更深入地看,我的config.xml文件与其余代码库位于不同的存储库中。因此,当我推送此补丁程序的更改时,配置文件未使用此更改进行更新。至于不写不存在的文件,我个人发现它可以在我的服务器上工作。让我想知道这是否是文件系统本身的文件夹权限问题。不过,我对代码的了解还不是很深。
PromInc

根据我的测试,如果文件已经存在,它可以工作。isValid进行的第一个检查是检查文件是否可读。如果不存在,则不尝试创建文件,并返回false。
勒内Schep

@RenéSchep,那么我们如何解决呢?Magento的支持是痛苦的时刻。他们的回复很慢。
Adarsh Khatri

@AdarshKhatri,您需要先创建文件,然后Magento才能写入文件。触摸/path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

Mage::log()如果最初不存在任何内容,则无法将任何内容写入日志文件。这是由于调用时会引发未发现错误的isValid功能。我已通过在实际创建日志文件后移至try / catch并通过以下操作来临时解决此问题:如果验证失败,则将其删除:Zend_Validate_File_ExtensionZend_Loader::isReadable($value)isValid

<?php
final class Mage
{
    ...
    public static function log($message, $level = null, $file = '', $forceLog = false)
    {
        ...

        try {
            if (!isset($loggers[$file])) {
                $logFile = $logDir . DS . $file;

                if (!is_dir($logDir)) {
                    mkdir($logDir);
                    chmod($logDir, 0750);
                }

                if (!file_exists($logFile)) {
                    file_put_contents($logFile, '');
                    chmod($logFile, 0640);
                }

                if (!$logValidator->isValid($logFile)) {
                    unlink($logFile);

                    return;
                }

        ...
    }
}

这绝对是一个临时解决方案,直到我们有了一些更坚实的基础为止


3

修补1.9.3.10时可能出现的问题

checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED

在补丁中,我们有:

diff --git app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
index 8d3c526c280..fde2ef0d45d 100644
--- app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
+++ app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
@@ -57,7 +57,7 @@ class Mage_Adminhtml_Block_Customer_Group_Edit extends Mage_Adminhtml_Block_Widg
                 'form_key' => Mage::getSingleton('core/session')->getFormKey()
             ));
         } else {
-            parent::getDeleteUrl();
+            return parent::getDeleteUrl();
         }
     }

但是,通过Mage LTS查看1.9.3.10上的代码,我没有看到有问题的代码:

https://github.com/OpenMage/magento-lts/blob/1.9.3.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

但是,它确实存在于1.9.4

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

可能的原因是以前未应用缺少的修补程序。


4
您缺少补丁SUPEE-10975。
理查德·费拉罗

嗯,根据我的补丁集,已经应用:2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | 2018年11月8日星期四13:45:47 +0200 | ce-1.9.3.10-dev
ProxiBlue

最新补丁程序的文件名是PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh,而您的文件名似乎是在2018年11月8日发布的,这不是我想的最新版本。
理查德·费拉罗

1
我还原了PATCH_SUPEE-10975并重新应用,然后重新应用了最新的,全部都起作用
ProxiBlue

这是SUPEE-10975中的错误,导致您无法删除客户组。看起来您是手动修复它,这导致此新补丁失败,这也正在修复它。
勒内Schep

3

尝试使用PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh在Magento 1.9.0.1上安装补丁我遇到了这个错误

Hunk #1 FAILED at 141.
1 out of 1 hunk FAILED

我通过从“ app / etc / config.xml”中删除以下代码,然后再次运行补丁来解决此问题

<dev>
    <template>
        <allow_symlink>0</allow_symlink>
    </template>
</dev>

3

我对M1补丁的命名也有些困惑。

对于较旧的补丁程序,他们将它们命名为SUPEE-10975 for CE 1.9.3.4-1.9.3.10或,SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)但是现在仅解决一个版本PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh

当前的补丁程序是针对次要版本的所有版本还是仅针对最后一个版本的版本?

我对1.9.3.1商店进行了测试,所有过程都通过了,但是我不确定这是否适用于其他版本?


谢谢瑞安!那也回答了@jason问题:“有人知道为什么没有针对1.8.0 / 1.8.1的版本吗?” 为此,他应该使用1.7.0.2补丁,对吗?之前不知道有解决多个次要发行版的补丁。
塞巴斯蒂安

2
你确定@RyanHoerr吗?并非相反,因为它假定在另一个线程magento.stackexchange.com/questions/267576/…上?看来,如果我们从旧的命名方式中猜测,PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh的适用范围可能是1.7.0.0至1.7.0.2,因此,在这种情况下,每个补丁中的版本号将是最后一个。Magento的任何人都可以确认这种命名方式背后的逻辑是什么?提前
致谢

2
我将使用@AntoineKociuba使用2个不同的1.8.1存储库,我遇到了4个1.7.0.2修补程序失败:-app / code / core / Mage / Usa / etc / system.xml Hunk#4 FAILED at 845-app /etc/config.xml Hunk#1失败-144-app / locale / en_US / Mage_Widget.csv Hunk#1失败-6-lib / Varien / Filter / Template.php Hunk#2失败254,而1.9.1.0运行顺利。与1.9.3.1存储库相同:修补程序1.9.2.4起作用,而1.9.3.10起作用。
塞巴斯蒂安

3
@RyanHoerr,这是不正确的。该名称包括补丁程序适用的最新版本。因此,适用于1.9.3.10的补丁适用于1.9.3.10、1.9.3.9...。我们将在下一个发行版中尝试改善命名,您也可以使用github.com/steverobbins/magedownload-cli,因为它应该可以通过API正确查看版本元数据。
Piotr Kaminski

删除了我的错误信息。感谢您的更正。
Ryan Hoerr

2

Magento 1.9中的记录中断。要修复SUPEE-11086修补程序中的日志记录,请执行以下操作:

在app / Mage.php中:

-        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         $logDir = self::getBaseDir('var') . DS . 'log';
-        if (!$logValidator->isValid($logDir . DS . $file)) {
+        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
+        if (!$validatedFileExtension || !in_array($validatedFileExtension, $_allowedFileExtensions)) {

资源:https : //gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

我希望这有帮助!


1

M1补丁中的所有新PHP文件均具有未处理的模板变量

<?php
/**
 * {license_notice}
 *
 * @copyright   {copyright}
 * @license     {license_link}
 */

这不是问题,但看起来不准确。SUPEE-10975之后,我有同样的感觉。


1

我注意到不再创建日志文件,而仅在日志文件已经存在时才被写出问题。这似乎是由以下行引起的:

if (!$logValidator->isValid($logDir . DS . $file)) {

来自app / Mage.php。我通过使用旧逻辑解决了这个问题。因此,将以下行替换为:

if (!self::helper('log')->isLogFileExtensionValid($file)) {

0

检查文件app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php Hunk#1 FAILED at57。1之1失败

在补丁10975中,此时存在错误。返回语句丢失。也许您在应用补丁10975后修复了该错误,或​​者忽略了更改。该错误已在11086中修复。如果您已经调整/忽略了这一行代码,将导致您在应用新补丁时描述的错误。如果您已经自己修复了该错误,则只需删除补丁文件中的块,然后再次运行补丁即可。


1
我不得不恢复“少官方”补丁SUPEE-11043的SUPEE-11086工作
的Jeroen默朗- MageHost

0

使用SUPEE-11086 | 上面的Ryan Hoerr建议的CE_1.9.1.0。

正在应用SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | 2019年3月22日星期五18:40:11 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

符合CE_1.9.2.1

我在每个文件上都失败了。

我已成功将补丁应用到其他存储库。

核心代码未触及。

应用的补丁列表

SUPEE-6788
SUPEE-7405-CE-1-9-2-2
SUPEE-7405 
SUPEE-8788 
SUPEE-9652 
SUPEE-8967 
PATCH_SUPEE-9767_CE_1.9.3.0_v2
SUPEE-10266-CE-1.9.2.4
SUPEE-10415-ce-1.9.2.1
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10752_CE_v1.9.2.4
SUPEE-10888_CE_v1.9.2.4
SUPEE-10975_CE_v1.9.3.3

感谢@AntoineKociuba的澄清。我已经验证了以前的补丁程序都是正确的,但是当我为我的1.9.2.1安装应用如下所述的正确补丁程序PATCH_SUPEE-11086_CE_1.9.2.4_v1时,除了一个大块以外,我仍然遇到错误。您会建议手动打补丁吗?
Bevan Holman

您在哪个大块上失败?
勒内Schep

这个问题已经解决了,我不得不重新获得一个仓库的克隆。由于勒内
贝文·霍尔曼

0

M1.9.3.7补丁PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh的问题

checking file app/Mage.php
checking file app/code/core/Mage/Admin/Model/Session.php
checking file app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED
checking file app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/System/Design/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/System/Store/Edit.php
checking file app/code/core/Mage/Adminhtml/Controller/Action.php
checking file app/code/core/Mage/Adminhtml/Helper/Data.php
checking file app/code/core/Mage/Adminhtml/Model/Email/PathValidator.php
checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED

视为app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php失败。我假设您已应用补丁SUPEE-11043,而SUPEE-11086则认为您尚未完成。
勒Schep

0

可以尝试SUPEE-11086在新下载并完全修补的1.9.1.1版本上应用时确认存在问题,包括Admin Dashboard Charts Patch之前的所有内容,包括-MPERF-10509-CE-2019-03-13-06-31-24.diff

在以下文件中修补失败。

app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
app/code/core/Mage/Api2/Block/Adminhtml/Roles/Buttons.php

这些文件与v1.9.1.1下载的最初提交相比没有任何变化。从1.9.2.4安装文件中复制文件,应用SUPEE-11086,然后与v1.9.4.1源进行比较,确认它们现在匹配。

Magento v1.9.1.1 看来孩子有点问题...


我只是将1.9.2.4补丁与1.9.1.0补丁进行了比较。看来,这些补丁之间的区别是您提到的3个文件。因此,看起来应该在1.9.1.1。上使用1.9.1.0补丁。
勒内Schep

0

可以尝试SUPEE-11086在新下载并完全修补的1.9.3.0版本上应用时确认存在问题,包括Admin Dashboard Charts Patch之前的所有内容,包括-MPERF-10509-CE-2019-03-13-06-31-24.diff

缺少以下节点,导致app / config.xml中的修补失败。在运行SUPEE-11086之前添加节点,没有问题。

<config>
    </default>
        <dev>
            <template>
                <allow_symlink>0</allow_symlink>
            </template>
        </dev>
    </default>
</config>

0

我发现模型有新问题 Mage_Eav_Model_Attribute_Data_File

在客户实体上,我添加了文件上传属性。这些属性不是必需的,并且当我要删除文件而不上传新文件时,删除不起作用,因为该属性值未通过新方法验证setAttributeValidationAsPassed()

我已经完成的快速修复方法 validateValue($value)

if (!$attribute->getIsRequired() && !$toUpload) {
    $attribute->setAttributeValidationAsPassed(); // this new line is added 
    return true;
}

此问题似乎在所有Magento 1.x版本中都存在 SUPEE-11086


0

Magento 1.9.3.1

尝试使用修补程序PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh修补CE 1.9.3.1时发生问题:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.