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

24

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.

Ryan Hoerr
źródło
Ryan Hoerr, myślę, że musisz utworzyć inne pytanie dotyczące aktualizacji bezpieczeństwa Magento 2.3.1, 2.2.8 i 2.1.17
Amit Bera
2
Masz pojęcie, dlaczego nie ma wersji 1.8.0 / 1.8.1?
Jason

Odpowiedzi:

20

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.

Aswerer
źródło
Ten problem dotyczy także Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
Aad Mathijssen
5
wszystkie moje logi zatrzymały się całkowicie. Nawet dzienniki systemowe i dzienniki wyjątków. Czy można to naprawić?
Kalvin Klien
wszystkie moje pliki dziennika napisane przez Mage :: log również się zatrzymały. M1 EE 1.14.0.2
PromInc
jedyną poprawką jest zwrócenie koduMage::log()
Aswerer
3
Od 25 czerwca Magento wydało SUPEE-11155, Magento Commerce 1.14.4.2 i Magento Open Source 1.9.4.2, które zawierają poprawkę do tej Mage::log()metody.
Aad Mathijssen
11

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.

Piotr Kamiński
źródło
5

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?

PromInc
źródło
3
To nie jest poprawne. W aplikacji / etc / config.xml dozwoloneFileExtensions zostało dodane jako konfiguracja. Jeśli nie ma go w bazie danych, zostanie użyty. Rzeczywistym problemem jest to, że nowa funkcja sprawdzania poprawności najpierw próbuje sprawdzić, czy plik już istnieje, czego może nie chcieć.
René Schep
Dziękujemy za wskazanie tego @ RenéSchep Widzę teraz tę zmianę w łatce. Patrząc głębiej, mój plik config.xml znajduje się w innym repozytorium niż reszta naszej bazy kodu. Z tego powodu, kiedy opublikowałem zmianę dla tej poprawki, plik konfiguracyjny nie został zaktualizowany o tę zmianę. Jeśli chodzi o nie pisanie do nieistniejących plików, osobiście uważam, że to działa na moich serwerach. Zastanawiam się, czy jest to problem z uprawnieniami do folderu w samym systemie plików. Jednak nie zagłębiłem się zbytnio w ten kod.
PromInc
Z tego, co przetestowałem, jest to, że działa, jeśli plik już istnieje. Pierwszym sprawdzeniem, które wykonuje isValid, jest sprawdzenie, czy plik jest czytelny. Jeśli nie istnieje, nie ma próby utworzenia pliku i zwracana jest wartość false.
René Schep
@ RenéSchep, więc jak to naprawić? Wsparcie Magento to ból w ** a. Bardzo wolno odpowiadają.
Adarsh ​​Khatri
@AdarshKhatri musisz utworzyć plik, zanim Magento będzie mógł do niego zapisać. dotknij /path/to/magento/install/html/var/log/newlogfile.log
PromInc
4

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

Daniel Doyle
źródło
3

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.

ProxiBlue
źródło
4
Brakuje ci poprawki SUPEE-10975.
Richard Feraro
mmm, zgodnie z moimi zestawami poprawek, który jest już zastosowany: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Czw 8 listopada 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue
Nazwa najnowszej łatki to PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh, podczas gdy twoja wydaje się być wydana w dniu 8 listopada 2018 r., Co nie jest najnowszą.
Richard Feraro
1
Cofnąłem PATCH_SUPEE-10975 i ponownie zastosowałem, a następnie ponownie zastosowałem najpóźniej, wszystkie działały
ProxiBlue
Był to błąd w SUPEE-10975, który spowodował, że nie można było usunąć grup klientów. Wygląda na to, że naprawiłeś go ręcznie, co powoduje awarię tej nowej poprawki, która również to naprawia.
René Schep
3

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>
rupi
źródło
3

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ń?

Sebastian
źródło
Dziękuję Ryan! To odpowiada również na pytanie Jasona „Wiesz, dlaczego nie ma wersji 1.8.0 / 1.8.1?” W tym celu powinien skorzystać z łatki 1.7.0.2, prawda? Nie wiedziałem, że wcześniej były łatki dotyczące wielu mniejszych wydań.
Sebastian
2
jesteś pewien @RyanHoerr? Czy nie jest odwrotnie, jak przypuszcza się w innym wątku magento.stackexchange.com/questions/267576/... ? Wygląda na to, że jeśli domyślimy się starego stylu nazewnictwa, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh można zastosować od 1.7.0.0 do 1.7.0.2, a zatem numer wersji w każdej łatce byłby w tym przypadku ostatnim . Czy ktoś z Magento mógłby potwierdzić logikę tego nowego stylu nazywania, proszę? Dziękuję z góry ..
Antoine Kociuba
2
Pójdę z @AntoineKociuba Z 2 różnymi sklepami 1.8.1, na które napotykam 4 błędy z łatką 1.7.0.2: - app / code / core / Mage / Usa / etc / system.xml Hunk # 4 FAILED at 845 - app /etc/config.xml Hunk # 1 FAILED at 144 - app / locale / en_US / Mage_Widget.csv Hunk # 1 FAILED at 6 - lib / Varien / Filter / Template.php Hunk # 2 FAILED at 254 podczas gdy 1.9.1.0 działa płynnie. To samo ze sklepem 1.9.3.1: łatka 1.9.2.4 nie działa, podczas gdy 1.9.3.10 działa.
Sebastian
3
@RyanHoerr to jest niepoprawne. Nazwa zawiera najnowszą wersję, której dotyczy łatka. 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ć github.com/steverobbins/magedownload-cli, ponieważ powinien on poprawnie wyświetlać metadane wersji w interfejsie API.
Piotr Kamiński
Usunąłem moje złe informacje. Dziękuję za poprawienie mnie.
Ryan Hoerr
2

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!

Mike Dubs
źródło
1

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.

Michaił Chelevich
źródło
1

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)) {
rupi
źródło
0

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ę.

Magento Sharingan
źródło
1
Musiałem przywrócić „mniej oficjalną” łatkę SUPEE-11043 dla SUPEE-11086 do działania
Jeroen Vermeulen - MageHost
0

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
Bevan Holman
źródło
Dzięki @AntoineKociuba za wyjaśnienie. Sprawdziłem, czy wszystkie poprzednie poprawki były poprawne, ale kiedy zastosuję poprawną poprawkę, jak podano poniżej PATCH_SUPEE-11086_CE_1.9.2.4_v1 dla mojej instalacji 1.9.2.1, nadal pojawia się błąd na wszystkich przystojniakach oprócz jednego. Czy zaproponowałbyś ręczną łatkę?
Bevan Holman
Na którym kawałku się nie udaje?
René Schep
Zostało to rozwiązane, musiałem zdobyć nowego klona repozytorium. Dzięki René
Bevan Holman
0

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
Roy Toledo
źródło
Wyświetlanie jako app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php nie powiodło się. Zakładam, że zastosowałeś łatkę SUPEE-11043, której SUPEE-11086 zakłada, że ​​nie zrobiłeś.
René Schep
0

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 ...

Słodkie jabłko
źródło
Właśnie porównałem łatkę 1.9.2.4 z łatką 1.9.1.0. I wygląda na to, że różnica między tymi łatkami to 3 pliki, o których wspominasz. Wygląda więc na to, że łatka 1.9.1.0 powinna być używana w wersji 1.9.1.1.
René Schep
0

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>
Słodkie jabłko
źródło
0

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

Laurent Tastet
źródło
0

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
Aditya Putra
źródło