Патч безпеки 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 Open Source до 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 Support в цьому питанні, але відповіді від техніка ще не отримав. Я в черзі.

Що мене справді бентежить у цій помилці, це те, що 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в спробу / 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 мають не оброблені варіанти шаблонів

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

Це не проблема, але виглядає неточно. У мене було те саме відчуття після SUPEE-10975.

Я помітив проблему з файлами журналів, які вже не створюються, а виписуються лише тоді, коли файл журналу вже існує. Схоже, це викликано рядком:

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

з програми / Mage.php. Я виправив це за допомогою старої логіки. Тому замініть рядок вище таким:

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

перевірка файлового додатка / код / ​​core / Mage / Adminhtml / Блок / Клієнт / Група / Edit.php Hunk №1 НЕПОСТАВЛЕНО в 57. 1 з 1 пар

У патчі 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