Poprawka bezpieczeństwa SUPEE-11086 - Możliwe problemy?

Magento wydało nową łatkę bezpieczeństwa dla M1 oraz aktualizacje dla M1 i M2.

Te wydania zawierają krytyczne poprawki bezpieczeństwa. „Zdecydowanie zalecamy, aby wszyscy kupcy dokonali aktualizacji jak najszybciej”.

Na jakie problemy należy zwrócić uwagę podczas aktualizacji lub stosowania tej poprawki?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 i Open Source 1.9.4.1 zawierają wiele ulepszeń bezpieczeństwa, które pomagają zamknąć zdalne wykonywanie kodu (RCE), cross-site scripting (XSS), fałszowanie żądań między witrynami (CSRF) i inne podatności.

Aktualizacja zabezpieczeń Magento 2.3.1, 2.2.8 i 2.1.17

Te wersje zawierają wiele aktualizacji funkcjonalnych i bezpieczeństwa. Ryzyko: krytyczne dla Magento Commerce i Magento Open Source przed 2.1.17, 2.2.8 i 2.3.1.

Największy znaleziony problem: Mage::log()działa niepoprawnie. Jeśli wywołasz tę funkcję z niestandardowym plikiem dziennika (a on jeszcze nie istnieje), dziennik nie zostanie zapisany do pliku z powodu dodatkowej weryfikacji, dodanej w SUPEE-11086.

Ważne: nazwa poprawki obejmuje najwyższą wersję, której dotyczy poprawka. Tak więc łatka dla wersji 1.9.3.10 miałaby zastosowanie do wersji 1.9.3.10, 1.9.3.9, .... aż do innej poprawki. Postaramy się poprawić nazewnictwo w następnej wersji. Możesz także użyć https://github.com/steverobbins/magedownload-cli, ponieważ powinien on poprawnie wyświetlać metadane wersji w interfejsie API.

Podobnie jak inne, miałem pliki dziennika całkowicie przestały zapisywać dane.

Źródło błędu - pliki dziennika nie zapisują danych

W app/Mage.phpzrobili tę zmianę:

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

która szuka konfiguracji zatwierdzonej oddzielonych przecinkami listy zatwierdzonych rozszerzeń plików. NIE dodali jednak tej listy do konfiguracji - nawet nie ma opcji w Administratorze Maga, abyśmy mogli skonfigurować ją samodzielnie.

Rozwiązanie problemu - pliki dziennika nie zapisują danych

Aby rozwiązać ten problem, po prostu wprowadź dane do bazy danych w core_config_datatabeli.

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

Wyczyść także pamięć podręczną obiektów i powinieneś ponownie zobaczyć zapis danych do plików dziennika.

ls -lrt var/log/ | tail

Dla odniesienia ten problem dotyczy EE 1.14.2.0 ze wszystkimi zastosowanymi poprawkami zabezpieczeń.

Otworzyłem zgłoszenie do pomocy technicznej Magento w tej sprawie, ale nie otrzymałem jeszcze odpowiedzi od technika. Jestem w kolejce.

To, co naprawdę dezorientuje mnie w tym błędzie, to fakt, że Magento ma już metodę sprawdzania poprawności rozszerzeń plików dziennika, które dodały za pośrednictwem SUPEE-10415 pod koniec 2017 roku.

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

Dlaczego nie wykorzystali tej logiki zamiast próby niepełnego ponownego wynalezienia koła z bali?

Mage::log()nie zapisuje niczego do plików dziennika, jeśli początkowo nie istnieją. Wynika to z isValidfunkcji Zend_Validate_File_Extensionzgłaszania błędu nie znalezionego podczas wywoływania Zend_Loader::isReadable($value). Tymczasowo naprawiłem to, przechodząc isValiddo try / catch po utworzeniu pliku dziennika, a następnie usuwając go, jeśli sprawdzanie poprawności się nie powiedzie:

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

        ...
    }
}

Jest to zdecydowanie tymczasowe rozwiązanie, dopóki nie będziemy mieli czegoś bardziej solidnego

Możliwy problem z łataniem 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

W patchu mamy:

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

jednak patrząc na kod z 1.9.3.10 (przez maga LTS) nie widzę tego kodu:

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

ALE istnieje dla wersji 1.9.4

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

Możliwym powodem jest brakująca łatka, która nie była wcześniej stosowana.

Próbuję zainstalować łatkę na Magento 1.9.0.1 przy użyciu PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Wystąpił ten błąd

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

Naprawiłem to, usuwając następujący kod z „app / etc / config.xml”, a następnie ponownie uruchamiając łatkę

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

Jestem również trochę zdezorientowany co do nazewnictwa łat M1.

Dla starszych plastrów nazwali je lubi SUPEE-10975 for CE 1.9.3.4-1.9.3.10albo SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)ale teraz to zajęcie tylko jedną wersję PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

Czy bieżąca łatka dotyczy wszystkich wydań wersji mniejszej, czy tylko ostatniej?

Zrobiłem test w sklepie 1.9.3.1 i wszystko przeszło, ale nie jestem pewien, czy jest to poprawne w przypadku innych wydań?

Rejestrowanie przerw w Magento 1.9. Aby naprawić logowanie w łatce SUPEE-11086:

W 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)) {

Zasób: https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

Mam nadzieję, że to pomoże!

Wszystkie nowe pliki PHP w łatce dla M1 mają nieprzetworzone zmienne szablonów

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

Nie jest to problem, ale wygląda na niedokładny. Tak samo czułem się po SUPEE-10975.

Zauważyłem problem z tym, że pliki dziennika nie są już tworzone i są zapisywane tylko wtedy, gdy plik dziennika już istnieje. Wygląda na to, że jest to spowodowane linią:

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

z app / Mage.php. Naprawiłem to za pomocą starej logiki. Więc zamień powyższy wiersz na następujący:

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

sprawdzanie aplikacji / kodu / rdzenia / Maga / Adminhtml / Block / Customer / Group / Edit.php Przystojniak # 1 NIEudany na 57. 1 na 1 przystojniak NIEudany

W aktualizacji 10975 wystąpił błąd w tym momencie. Brakowało instrukcji zwrotu. Być może naprawiłeś ten błąd po zastosowaniu łatki 10975 lub zignorowałeś zmianę. Błąd został naprawiony w 11086. Jeśli ten wiersz kodu został już przez ciebie dostosowany / zignorowany, spowoduje to błąd, który opisałeś podczas stosowania nowej łatki. Jeśli sam naprawiłeś już błąd, po prostu usuń blok z pliku łatki i ponownie uruchom łatkę.

Korzystanie z SUPEE-11086 | CE_1.9.1.0, jak sugeruje Ryan Hoerr powyżej.

Stosowanie SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Pt 22 marca 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

Do CE_1.9.2.1

Dostaję błąd dla każdego pliku.

Z powodzeniem zastosowałem łatkę do innych repozytoriów.

Kod rdzenia nietknięty.

Lista zastosowanych poprawek

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

Problemy z poprawką 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

Potwierdza, że ​​istnieje problem przy próbie zastosowania SUPEE-11086na nowo pobranej i w pełni poprawionej wersji 1.9.1.1, w tym wszystko, włącznie z łatką Admin Dashboard Charts -MPERF-10509-CE-2019-03-13-06-31-24.diff

Łatka nie działa w następujących plikach.

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

Te pliki nie mają żadnych zmian w porównaniu z początkowym zatwierdzeniem pobierania wersji 1.1.9.1. Skopiowanie plików z instalacji 1.9.2.4, zastosowanie SUPEE-11086, a następnie porównanie ze źródłem v1.9.4.1 potwierdza, że ​​teraz pasują.

Magento v1.9.1.1 wydaje się być problematycznym dzieckiem ...

Potwierdza, że ​​występuje problem przy próbie zastosowania SUPEE-11086na nowo pobranej, w pełni poprawionej wersji 1.9.3.0, w tym wszystko, włącznie z łatką Admin Dashboard Charts -MPERF-10509-CE-2019-03-13-06-31-24.diff

Łata nie działa w app / config.xml, ponieważ brakuje węzła poniżej. Dodaj węzeł przed uruchomieniem SUPEE-11086, bez problemów.

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

Odkryłem nowy problem z modelem Mage_Eav_Model_Attribute_Data_File

W jednostce klientów dodałem atrybuty przesyłania plików. Te atrybuty nie są wymagane, a gdy chcę usunąć plik bez przesłania nowego, usunięcie nie działa, ponieważ wartość atrybutu nie jest sprawdzana za pomocą nowej metodysetAttributeValidationAsPassed()

Szybka poprawka, którą zrobiłem, jest w metodzie validateValue($value)

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

Ten problem wydaje się występować we wszystkich wydaniach Magento 1.x od tego czasu SUPEE-11086

Magento 1.9.3.1

Wystąpił problem podczas próby łatania CE 1.9.3.1 przy użyciu poprawki 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