Исправление безопасности SUPEE-11086 - Возможные проблемы?

Magento выпустила новое исправление безопасности для M1 и обновления для M1 и M2.

Эти выпуски включают критические исправления безопасности. «Мы настоятельно рекомендуем всем торговцам обновиться как можно скорее».

Какие проблемы я должен учитывать при обновлении или применении этого патча?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 и Open Source 1.9.4.1 содержат множество улучшений безопасности, которые помогают закрыть удаленное выполнение кода (RCE), межсайтовый скриптинг (XSS), подделку межсайтовых запросов (CSRF) и другие уязвимости.

Обновление безопасности для Magento 2.3.1, 2.2.8 и 2.1.17

Эти версии содержат несколько обновлений функций и безопасности. Риск: критический для Magento Commerce и Magento с открытым исходным кодом до 2.1.17, 2.2.8 и 2.3.1.

Самая большая проблема, которая была найдена: Mage::log()работает неправильно. Если вы вызываете эту функцию с пользовательским файлом журнала (а он еще не существует), журнал не будет записан в файл из-за дополнительной проверки, добавленной в SUPEE-11086.

Важно: имя патча включает самую высокую версию, к которой применяется патч. Таким образом, патч для 1.9.3.10 будет применяться к 1.9.3.10, 1.9.3.9, .... вплоть до другого патча. Мы постараемся улучшить именование в следующем выпуске, и вы также можете использовать https://github.com/steverobbins/magedownload-cli, поскольку он должен правильно видеть метаданные версий через API.

Как и у других, у меня были файлы журналов, которые полностью прекращали записывать данные.

Источник ошибки - файлы журнала не записывают данные

В 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 уже есть метод проверки расширений лог-файлов, который они добавили через SUPEE-10415 в конце 2017 года.

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;
    }

Почему они не использовали эту логику вместо попытки неполного переизобретения колеса?

Mage::log()не может ничего записать в файлы журнала, если они не существуют изначально. Это связано с isValidфункцией Zend_Validate_File_Extensionвыдачи не найденной ошибки при вызове Zend_Loader::isReadable($value). Я временно исправил это, перейдя isValidв try / catch после фактического создания файла журнала, а затем удалив файл, если проверка не удалась:

<?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;
                }

        ...
    }
}

Это определенно временное решение, пока у нас не появится что-то более солидное

Возможная проблема с исправлениями 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();
         }
     }

однако, глядя на код в 1.9.3.10 (через мага LTS), я не вижу этот код в вопросе:

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

Возможная причина - отсутствующий патч, ранее не примененный.

Попытка установить патч на Magento 1.9.0.1 с помощью PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Я столкнулся с этой ошибкой

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

Я исправил это, удалив следующий код из «app / etc / config.xml», а затем снова запустив патч

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

Я также немного озадачен именами патчей 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, и все прошло, но я не совсем уверен, верно ли это для других выпусков?

Регистрация разрывов в Magento 1.9. Чтобы исправить запись в патче SUPEE-11086:

В приложении / 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

Надеюсь, это поможет!

Все новые файлы PHP в патче для M1 имеют необработанные шаблоны vars

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

Не проблема, но выглядит неточно. У меня было такое же чувство после SUPEE-10975.

Я заметил проблему с файлами журналов, которые больше не создаются и записываются, только если файл журнала уже существует. Похоже, это вызвано строкой:

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

из приложения / Mage.php. Я исправил это, используя старую логику. Поэтому замените строку выше следующим:

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

проверка файла приложения / кода / ядра / Mage / Adminhtml / блокировки / клиента / группы / Edit.php Hunk # 1 FAILED на 57. 1 из 1 блока Hailled

В патче 10975 на этом этапе произошла ошибка. Обратное заявление отсутствовало. Возможно, вы исправили эту ошибку после применения патча 10975 или проигнорировали это изменение. Ошибка была исправлена ​​в 11086. Если эта строка кода уже была откорректирована / проигнорирована вами, это приведет к ошибке, описанной вами при применении нового патча. Если вы уже исправили ошибку самостоятельно, просто удалите блок из файла патча и снова запустите патч.

Использование SUPEE-11086 | CE_1.9.1.0, как предложено Райаном Херром выше.

Применение SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Пт мар 22 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

К CE_1.9.2.1

Я получаю Fail на каждом файле.

Я успешно применил патч к другим репозиториям.

Основной код не тронут.

Список примененных патчей

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

Проблемы с патчем 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

Может подтвердить, что существует проблема при попытке применить SUPEE-11086к недавно загруженной и полностью исправленной версии 1.9.1.1, включая все, вплоть до исправления диаграмм панели администратора, -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 действительно кажется немного проблемным ребенком ...

Может подтвердить, что существует проблема при попытке применить SUPEE-11086к недавно загруженной и полностью исправленной версии 1.9.3.0, включая все, вплоть до исправления диаграмм панели администратора: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>

Я обнаружил новую проблему с моделью 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

Magento 1.9.3.1

Произошла ошибка при попытке установить исправление CE 1.9.3.1 с помощью исправления PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED