Исправление безопасности 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.