Sicherheitspatch SUPEE-11086 - Mögliche Probleme?


24

Magento hat einen neuen Sicherheitspatch für M1 und Updates für M1 und M2 veröffentlicht.

Diese Releases enthalten wichtige Sicherheitsupdates. "Wir empfehlen allen Händlern dringend, so schnell wie möglich ein Upgrade durchzuführen."

Auf welche Probleme sollte ich achten, wenn ich diesen Patch aktualisiere oder anwende?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 und Open Source 1.9.4.1 enthalten mehrere Sicherheitsverbesserungen, die das Beenden von RCE (Remote Code Execution), XSS (Cross Site Scripting), CSRF (Cross Site Request Forgery) und anderen Sicherheitsanfälligkeiten unterstützen.

Magento 2.3.1, 2.2.8 und 2.1.17 Sicherheitsupdate

Diese Versionen enthalten mehrere Funktions- und Sicherheitsupdates. Risiko: Kritisch für Magento Commerce und Magento Open Source vor 2.1.17, 2.2.8 und 2.3.1.


Ryan Hoerr, ich denke, Sie müssen eine andere Frage für Magento 2.3.1, 2.2.8 und 2.1.17 erstellen. Sicherheitsupdate
Amit Bera

2
Irgendeine Idee, warum es keine Version für 1.8.0 / 1.8.1 gibt?
Jason

Antworten:


20

Das größte Problem, das gefunden wurde: Mage::log()funktioniert nicht richtig. Wenn Sie diese Funktion mit einer benutzerdefinierten Protokolldatei aufrufen (und sie existiert noch nicht), wird das Protokoll aufgrund der zusätzlichen Validierung, die im SUPEE-11086 hinzugefügt wurde, nicht in die Datei geschrieben.


Dieses Problem betrifft auch Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
Aad Mathijssen

5
Alle meine Protokolle wurden vollständig gestoppt. Sogar System- und Ausnahmeprotokolle. Gibt es eine Lösung dafür?
Kalvin Klien

Alle meine Protokolldateien, in die Mage :: log geschrieben hat, wurden ebenfalls gestoppt. M1 EE 1.14.0.2
PromInc

Das einzige Mage::log()
Problem

3
Ab dem 25. Juni hat Magento SUPEE-11155, Magento Commerce 1.14.4.2 und Magento Open Source 1.9.4.2 veröffentlicht, die ein Update für die Mage::log()Methode enthalten.
Aad Mathijssen

11

Wichtig: Der Patchname enthält die höchste Version, auf die sich der Patch bezieht. Ein Patch für 1.9.3.10 würde also für 1.9.3.10, 1.9.3.9, ... bis auf einen anderen Patch zutreffen. Wir werden versuchen, die Benennung in der nächsten Version zu verbessern. Sie können auch https://github.com/steverobbins/magedownload-cli verwenden, da dort die Versionsmetadaten ordnungsgemäß über die API angezeigt werden sollen.


5

Wie andere hatte ich Log-Dateien vollständig aufhören, Daten zu schreiben.

Fehlerquelle - Protokolldateien, die keine Daten schreiben

Darin haben app/Mage.phpsie folgende Änderung vorgenommen:

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

Das sucht in der Konfiguration nach einer durch Kommas getrennten Liste der genehmigten Dateierweiterungen. Sie haben diese Liste jedoch NICHT in die Konfiguration aufgenommen - nicht einmal eine Option im Magieradministrator, um dies selbst zu konfigurieren.

Lösung für den Fehler - Protokolldateien, die keine Daten schreiben

Um dies zu lösen, machen Sie einfach einen Eintrag in die Datenbank in der core_config_dataTabelle.

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

Leeren Sie auch den Objektcache, und Sie sollten feststellen, dass erneut Daten in die Protokolldateien geschrieben werden.

ls -lrt var/log/ | tail


Zu Referenzzwecken wurde dieses Problem in EE 1.14.2.0 mit allen angewendeten Sicherheitspatches behoben.

Ich habe bei Magento Support ein Ticket zu diesem Thema geöffnet, aber noch keine Antwort von einem Techniker erhalten. Ich bin in der Warteschlange.


Was mich an diesem Fehler wirklich verwirrt, ist, dass Magento bereits eine Methode zur Überprüfung von Protokolldateierweiterungen hat, die Ende 2017 über SUPEE-10415 hinzugefügt wurden.

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

Warum haben sie diese Logik nicht wiederverwendet, anstatt zu versuchen, das Holzrad unvollständig neu zu erfinden?


3
Das ist nicht richtig. In der app / etc / config.xml wurde die allowedFileExtensions als Konfiguration hinzugefügt. Wenn es nicht in der Datenbank vorhanden ist, wird dies verwendet. Das eigentliche Problem besteht darin, dass die neue Validierungsfunktion zunächst versucht, festzustellen, ob die Datei bereits vorhanden ist, was möglicherweise nicht der Fall ist.
René Schep

Vielen Dank für den Hinweis @ RenéSchep Ich sehe diese Änderung jetzt im Patch. Wenn ich genauer hinschaue, befindet sich meine Datei config.xml in einem anderen Repository als der Rest unserer Codebasis. Aus diesem Grund wurde die Konfigurationsdatei nicht mit dieser Änderung aktualisiert, als ich die Änderung für diesen Patch vorgenommen habe. Ich persönlich finde, dass das Schreiben in nicht vorhandene Dateien auf meinen Servern funktioniert. Ich frage mich, ob dies ein Problem mit den Ordnerberechtigungen im Dateisystem selbst ist. Ich habe mir diesen Code jedoch nicht zu genau angesehen.
PromInc

Was ich getestet habe ist, dass es funktioniert, wenn die Datei bereits existiert. Die erste Prüfung, die isValid durchführt, ist die Prüfung, ob die Datei lesbar ist. Ist dies nicht der Fall, wird nicht versucht, die Datei zu erstellen, und es wird ein false zurückgegeben.
René Schep

@ RenéSchep also wie beheben wir das? Magento-Support ist eine harte Angelegenheit. Sie antworten sehr langsam.
Adarsh ​​Khatri

@AdarshKhatri Sie müssen die Datei erstellen, bevor Magento darauf schreiben kann. Berühren Sie /path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

Mage::log()kann nichts in die Protokolldateien schreiben, wenn diese anfänglich nicht vorhanden sind. Dies liegt an der isValidFunktion, Zend_Validate_File_Extensionbeim Aufruf einen nicht gefundenen Fehler auszulösen Zend_Loader::isReadable($value). Ich habe dies vorübergehend behoben, indem ich isValidnach der tatsächlichen Erstellung der Protokolldatei in try / catch gewechselt bin und die Datei dann entfernt habe, wenn die Validierung fehlgeschlagen ist:

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

        ...
    }
}

Dies ist definitiv eine vorübergehende Lösung, bis wir etwas Festeres haben


3

Mögliches Problem beim Patchen 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

Im Patch haben wir:

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

Wenn ich mir jedoch den Code vom 1.9.3.10 (über Magier LTS) ansehe, sehe ich diesen Code nicht in Frage:

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

ABER es existiert für 1.9.4

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

Möglicher Grund ist ein fehlender Patch, der zuvor nicht angewendet wurde.


4
Ihnen fehlt der Patch SUPEE-10975.
Richard Feraro

mmm, laut meinen Patchsets gilt das schon: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Do 8.11. 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue

Der Dateiname des neuesten Patches lautet PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh, während der Name Ihres Patches anscheinend am 8. November 2018 veröffentlicht wurde, was vermutlich nicht der neueste ist.
Richard Feraro

1
Ich habe PATCH_SUPEE-10975 zurückgesetzt und erneut angewendet, dann erneut angewendet, alles hat funktioniert
ProxiBlue

Dies war ein Fehler in SUPEE-10975, der dazu führte, dass Sie Kundengruppen nicht löschen konnten. Sieht so aus, als hätten Sie es manuell repariert, was dazu führt, dass dieser neue Patch fehlschlägt und dies ebenfalls behebt.
René Schep

3

Beim Versuch, den Patch unter Magento 1.9.0.1 mithilfe von PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh zu installieren, ist dieser Fehler aufgetreten

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

Ich habe dies behoben, indem ich den folgenden Code aus "app / etc / config.xml" entfernt und dann den Patch erneut ausgeführt habe

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

3

Ich bin auch etwas verwirrt über die Benennung der M1-Patches.

Für ältere Patches gaben sie den Namen " SUPEE-10975 for CE 1.9.3.4-1.9.3.10oder" SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB), jetzt wird nur noch eine Version angesprochen PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

Gilt der aktuelle Patch für alle Releases einer Nebenversion oder nur für die letzte?

Ich habe einen Test mit einem 1.9.3.1-Store durchgeführt und alles ist durchgegangen, aber ich bin mir nicht ganz sicher, ob das für andere Releases korrekt ist.


Vielen Dank, Ryan! Das beantwortet auch die @ Jason-Frage "Irgendeine Idee, warum es keine Version für 1.8.0 / 1.8.1 gibt?" Dafür sollte er mit dem 1.7.0.2 Patch gehen, oder? Wusste nicht, dass es Patches für mehrere kleinere Releases gab.
Sebastian

2
Bist du sicher, @RyanHoerr? Ist es nicht das Gegenteil, wie es in einem anderen Thread unter magento.stackexchange.com/questions/267576/… vermutet wird ? Es scheint, dass, wenn wir vom alten Benennungsstil ausgehen, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh von 1.7.0.0 auf 1.7.0.2 angewendet werden könnte Die Versionsnummer in jedem Patch ist in diesem Fall die letzte . Jeder von Magento könnte bestätigen, welche Logik hinter diesem neuen Benennungsstil steckt . Thx im Voraus ..
Antoine Kociuba

2
Ich werde mit @AntoineKociuba gehen. Mit 2 verschiedenen 1.8.1-Stores, in denen ich auf 4 stoße, schlägt der Patch 1.7.0.2 fehl /etc/config.xml Hunk # 1 FEHLGESCHLAGEN bei 144 - app / locale / de_DE / Mage_Widget.csv Hunk # 1 FEHLGESCHLAGEN bei 6 - lib / Varien / Filter / Template.php Hunk # 2 FEHLGESCHLAGEN bei 254, während 1.9.1.0 ausgeführt wird glatt. Dasselbe gilt für einen 1.9.3.1-Speicher: Der Patch 1.9.2.4 funktioniert nicht, wohingegen der 1.9.3.10 funktioniert.
Sebastian

3
@ RyanHoerr das ist falsch. Der Name enthält die neueste Version, auf die sich ein Patch bezieht. Ein Patch für 1.9.3.10 würde also für 1.9.3.10, 1.9.3.9, ... bis auf einen anderen Patch zutreffen. Wir werden versuchen, die Benennung in der nächsten Version zu verbessern. Sie können auch github.com/steverobbins/magedownload-cli verwenden, da dort die Versionsmetadaten ordnungsgemäß über die API angezeigt werden sollen.
Piotr Kaminski

Meine schlechten Informationen wurden entfernt. Danke für die Korrektur.
Ryan Hoerr

2

Protokollierungspausen in Magento 1.9. So beheben Sie die Protokollierung im SUPEE-11086-Patch:

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

Ressource: https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

Ich hoffe das hilft!


1

Alle neuen PHP-Dateien im Patch für M1 enthalten nicht verarbeitete Vorlagenvariablen

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

Kein Problem, sieht aber ungenau aus. Ich hatte das gleiche Gefühl nach SUPEE-10975.


1

Ich habe ein Problem festgestellt, bei dem keine Protokolldateien mehr erstellt und nur dann ausgeschrieben werden, wenn die Protokolldatei bereits vorhanden ist. Dies scheint durch die folgende Zeile verursacht zu werden:

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

von app / Mage.php. Ich habe das mit der alten Logik behoben. Ersetzen Sie daher die obige Zeile durch die folgende:

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

0

Datei überprüfen app / code / core / Mage / Adminhtml / Block / Kunde / Gruppe / Edit.php Hunk # 1 FAILED bei 57. 1 von 1 Hunk FAILED

In Patch 10975 ist zu diesem Zeitpunkt ein Fehler aufgetreten. Die return-Anweisung fehlte. Möglicherweise haben Sie diesen Fehler behoben, nachdem Sie Patch 10975 angewendet oder die Änderung ignoriert haben. Der Fehler wurde in 11086 behoben. Wenn diese Codezeile bereits von Ihnen angepasst / ignoriert wurde, führt dies zu dem Fehler, den Sie beim Anwenden des neuen Patches beschrieben haben. Wenn Sie den Fehler bereits behoben haben, entfernen Sie einfach den Block in der Patch-Datei und führen Sie den Patch erneut aus.


1
Ich musste den "weniger offiziellen" Patch SUPEE-11043 zurücksetzen, damit SUPEE-11086 funktioniert
Jeroen Vermeulen - MageHost

0

Verwenden von SUPEE-11086 | CE_1.9.1.0 wie oben von Ryan Hoerr vorgeschlagen.

SUPEE-11086 anwenden | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Fr 22 März 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

Zu CE_1.9.2.1

Ich erhalte für jede Datei einen Fehler.

Ich habe den Patch erfolgreich auf andere Repos angewendet.

Kerncode unberührt.

Liste der angewendeten Patches

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

Danke @AntoineKociuba für die Klarstellung. Ich habe überprüft, ob die vorherigen Patches alle korrekt waren, aber wenn ich den richtigen Patch wie unten angegeben für meine 1.9.2.1-Installation anwende, erhalte ich immer noch eine Fehlermeldung auf allen bis auf einen Hunk. Würden Sie einen manuellen Patch vorschlagen?
Bevan Holman

Auf welchem ​​Hunk versagst du?
René Schep

Dies wurde behoben, ich musste einen neuen Klon des Repos bekommen. Danke René
Bevan Holman

0

Probleme mit dem M1.9.3.7-Patch 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

Das Anzeigen als App / Code / Core / Magier / Adminhtml / Blockieren / Kunde / Gruppe / Bearbeiten.php ist fehlgeschlagen. Ich gehe davon aus, dass Sie den Patch SUPEE-11043 angewendet haben, von dem SUPEE-11086 annimmt, dass Sie dies nicht getan haben.
René Schep

0

Kann bestätigen, dass ein Problem vorliegt, wenn versucht wird, SUPEE-11086auf eine neu heruntergeladene und vollständig gepatchte Version von 1.9.1.1 anzuwenden, einschließlich aller Komponenten bis einschließlich Admin Dashboard Charts Patch -MPERF-10509-CE-2019-03-13-06-31-24.diff

Patch schlägt in den folgenden Dateien fehl.

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

Diese Dateien haben sich seit dem ersten Festschreiben des Downloads von Version 1.9.1.1 nicht geändert. Durch Kopieren von Dateien aus der Installation 1.9.2.4, Anwenden von SUPEE-11086 und anschließendes Vergleichen mit der Quelle v1.9.4.1 wird bestätigt, dass sie jetzt übereinstimmen.

Magento v1.9.1.1 scheint ein bisschen ein Sorgenkind zu sein ...


Ich habe gerade den 1.9.2.4-Patch mit dem 1.9.1.0-Patch verglichen. Und es sieht so aus, als ob der Unterschied zwischen diesen Patches in den drei Dateien besteht, die Sie erwähnen. Es sieht also so aus, als ob der 1.9.1.0-Patch für 1.9.1.1 verwendet werden sollte.
René Schep

0

Kann bestätigen, dass ein Problem vorliegt, wenn versucht wird, SUPEE-11086auf eine neu heruntergeladene und vollständig gepatchte Version von 1.9.3.0 anzuwenden.MPERF-10509-CE-2019-03-13-06-31-24.diff

Patch schlägt in app / config.xml fehl, da der unten stehende Knoten fehlt. Fügen Sie den Knoten ohne Probleme hinzu, bevor Sie SUPEE-11086 ausführen.

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

0

Ich habe ein neues Problem mit dem Modell entdeckt Mage_Eav_Model_Attribute_Data_File

Auf der Entität des Kunden habe ich Attribute zum Hochladen von Dateien hinzugefügt. Diese Attribute sind nicht erforderlich. Wenn ich eine Datei löschen möchte, ohne eine neue hochzuladen, funktioniert das Löschen nicht, da der Attributwert nicht über die neue Methode überprüft wirdsetAttributeValidationAsPassed()

Die schnelle Lösung, die ich getan habe, ist in der Methode validateValue($value)

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

Dieses Problem scheint in allen Magento 1.x-Releases seit vorhanden zu sein SUPEE-11086


0

Magento 1.9.3.1

Bei dem Versuch, CE 1.9.3.1 mit dem Patch PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh zu patchen, ist ein Problem aufgetreten:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.