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


24

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.


Райан Херр, я думаю, вам нужно создать другой вопрос для обновления безопасности Magento 2.3.1, 2.2.8 и 2.1.17
— Амит Бера

2
Есть идеи, почему нет версии для 1.8.0 / 1.8.1?
— Джейсон

Ответы:


20

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


Эта проблема также относится к Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
— Aad Mathijssen

5
все мои логи остановились полностью. Даже система и журналы исключений. можно ли это исправить?
— Кальвин Клиен

все мои файлы журналов, записанные Mage :: log, также остановились. M1 EE 1.14.0.2
— PromInc

единственное исправление - вернуть кодMage::log()
— Aswerer

3
По состоянию на 25 июня Magento выпустила SUPEE-11155, Magento Commerce 1.14.4.2 и Magento Open Source 1.9.4.2, которые включают исправление для Mage::log()метода.
— Аад Матейссен

11

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


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

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


3
Это не правильно. В app / etc / config.xml допускаемые расширения были добавлены в качестве конфигурации. Если он не существует в базе данных, он будет использован. Фактическая проблема заключается в том, что новая функция проверки сначала пытается определить, существует ли файл, что вполне возможно, что нет.
— Рене Шеп

Спасибо, что указали на @ RenéSchep. Я вижу это изменение в патче. Если посмотреть глубже, мой файл config.xml находится в другом репозитории, как и остальная часть нашей кодовой базы. По этой причине, когда я выдвинул изменение для этого патча, файл конфигурации не был обновлен с этим изменением. Что касается не записи в несуществующие файлы, я лично нахожу это для работы на моих серверах. Заставляет меня задуматься, если это проблема с разрешениями для папок в самой файловой системе. Однако я не слишком углубился в этот код.
— PromInc

Из того, что я проверял, это то, что он работает, если файл уже существует. Первая проверка, которую выполняет isValid, проверяет, доступен ли файл для чтения. Если он не существует, попытка создания файла не производится, и возвращается false.
— Рене Шеп

@ RenéSchep, как нам это исправить? Поддержка Magento - это боль в а ** ч. Они очень медленно отвечают.
— Адарш Хатри

@AdarshKhatri Вам нужно создать файл, прежде чем Magento сможет написать в него.
— Нажмите

4

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

        ...
    }
}

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


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

однако, глядя на код в 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

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


4
Вы пропустили патч SUPEE-10975.
— Ричард Фераро

ммм, в соответствии с моими наборами патчей, которые уже применяются: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Чт 8 ноября 13:45:47 2018 +0200 | ce-1.9.3.10-dev
— ProxiBlue

Имя файла последнего патча: PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh, в то время как ваш, кажется, выпущен 8 ноября 2018 года, что, я полагаю, не является последним.
— Ричард Фераро

1
Я вернул PATCH_SUPEE-10975 и повторно применил, затем повторно применил последний, все работало
— ProxiBlue

Это ошибка в SUPEE-10975, из-за которой вы не смогли удалить группы клиентов. Похоже, вы исправили это вручную, что приводит к сбою этого нового патча, который также исправляет это.
— Рене Шеп

3

Попытка установить патч на 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>

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 FAILED в 144 - app / locale / en_US / Mage_Widget.csv Hunk # 1 FAILED в 6 - lib / Varien / Filter / Template.php Hunk # 2 FAILED в 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.
— Петр Каминский

Убрал мою плохую информацию. Спасибо за исправление.
— Райан Херр

2

Регистрация разрывов в 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

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


1

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

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

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


1

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

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

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

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

0

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

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


1
Мне пришлось вернуть «менее официальный» патч SUPEE-11043 для SUPEE-11086 для работы
— Jeroen Vermeulen - MageHost

0

Использование 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

Спасибо @AntoineKociuba за разъяснения. Я проверил, что все предыдущие исправления были правильными, но когда я применяю правильное исправление, как указано ниже PATCH_SUPEE-11086_CE_1.9.2.4_v1 для моей установки 1.9.2.1, я все еще получаю ошибку на всех, кроме одного блока. Вы бы предложили ручной патч?
— Беван Холман

Какой кусок ты терпишь неудачу?
— Рене Шеп

Это было решено, мне пришлось получить новый клон репо. Спасибо Рене
— Беван Холман

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, вы еще не сделали.
— Рене Шеп

0

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


Я только что сравнил патч 1.9.2.4 с патчем 1.9.1.0. И похоже, что разница между этими патчами - это те 3 файла, которые вы упомянули. Похоже, патч 1.9.1.0 следует использовать на 1.9.1.1.
— Рене Шеп

0

Может подтвердить, что существует проблема при попытке применить 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>

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

Произошла ошибка при попытке установить исправление 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
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.