Sicherheitspatch SUPEE-11086 - Mögliche Probleme?

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.

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.

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.

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?

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

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.

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>

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.

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!

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.

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

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.

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

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

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

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>

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

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