Magento-Sicherheitspatch SUPEE-6482, Was ist gepatcht?

Heute, den 04.08.2015, wurde ein neuer Sicherheitspatch veröffentlicht. Einige Kollegen und ich haben den Patch überprüft. Es ist immer schön, eine Diskussion darüber zu führen, was sich geändert hat. Weiß auch jemand, welche möglichen Angriffe sich auf einen ungepatchten Shop auswirken könnten? Was ist das Schlimmste, was passieren könnte?

Update: Ich wollte nur die E-Mail hinzufügen, die Magento heute gesendet hat, um den Beitrag zu vervollständigen.

Der eigentliche Sicherheitspatch ( SUPEE-6482 ) wirkt sich nur auf die beiden folgenden Dateien aus und ist ein API-Patch.

app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
app/code/core/Mage/Catalog/Model/Product/Api/V2.php

Die vollständige 1.9.2.1-Installation ist eine ganz andere Sache. Ich würde den Quellcode zwischen 1.9.2.0 und 1.9.2.1 unterscheiden, um die beiden anderen Elemente herauszufinden, die gepatcht wurden.

Versionshinweise gelten für das vollständige Installationsprogramm. Sie müssen den Patch überprüfen, um festzustellen, ob er tatsächlich alle in den Versionshinweisen aufgeführten Elemente enthält.

Auswirkungen der Ausführung eines nicht gepatchten Servers:

1. Cross-Site Scripting mit nicht validierten Headern => Cache Poisoning
2. Autoloaded File Inclusion in der Magento SOAP API => Remote Code Autoload
3. XSS in der Gift Registry Search => Cookie-Diebstahl und Benutzeridentität
4. SSRF-Sicherheitsanfälligkeit in WSDL-Datei => Internes Server-Informationsleck und Einbeziehung von Remotedateien

HINWEIS: Dateien, die im vollständigen Installationsarchiv gepatcht wurden und nicht mit dem Patch gepatcht wurden, hmm?

diff -r magento-1920/app/code/core/Mage/Core/Controller/Request/Http.php magento-1921/app/code/core/Mage/Core/Controller/Request/Http.php
300a301
>         $host = $_SERVER['HTTP_HOST'];
302,303c303,304
<             $host = explode(':', $_SERVER['HTTP_HOST']);
<             return $host[0];
---
>             $hostParts = explode(':', $_SERVER['HTTP_HOST']);
>             $host =  $hostParts[0];
305c306,313
<         return $_SERVER['HTTP_HOST'];
---
> 
>         if (strpos($host, ',') !== false || strpos($host, ';') !== false) {
>             $response = new Zend_Controller_Response_Http();
>             $response->setHttpResponseCode(400)->sendHeaders();
>             exit();
>         }
> 
>         return $host;

diff -r magento-1920/app/design/frontend/base/default/template/page/js/cookie.phtml magento-1921/app/design/frontend/base/default/template/page/js/cookie.phtml
37,38c37,38
< Mage.Cookies.path     = '<?php echo $this->getPath()?>';
< Mage.Cookies.domain   = '<?php echo $this->getDomain()?>';
---
> Mage.Cookies.path     = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getPath()) ?>';
> Mage.Cookies.domain   = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getDomain()) ?>';

Ich habe mir die Veränderungen im Detail angeschaut und mit welchen Nebenwirkungen zu rechnen ist.

In der Version für EE 1.13.1.0 wurden folgende Dateien geändert:

2015-08-05 07:14:25 UTC | SUPEE-6482_EE_1.13.1.0 | EE_1.13.1.0 | v2 | 7e38036f94f250514fcc11d066a43c9bdb6a3723 | Tue Jul 28 14:29:35 2015 +0300 | v1.13.1.0..HEAD
patching file app/code/core/Enterprise/PageCache/Model/Processor.php
patching file app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
patching file app/code/core/Mage/Catalog/Model/Product/Api/V2.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 294 (offset 7 lines).
patching file app/design/frontend/base/default/template/page/js/cookie.phtml
patching file app/design/frontend/enterprise/default/template/giftregistry/search/form.phtml

• In Adapter/Soap.phpwird den Authentifizierungsdaten eine Urlencodierung hinzugefügt. Dies sollte keine negativen Nebenwirkungen haben. Es wird sichergestellt, dass das Ergebnis wsdlUrlgültig ist. Ohne diese Änderung könnte man die URL beeinflussen
• Product/Api/V2.php: Hier einige Überprüfungen, ob übergebene Daten ein Objekt sind. Dies sollte unter normalen Umständen nicht passieren.
• in Request/Http.phpund PageCache/Model/Processor.phpein Häkchen wird hinzugefügt, wenn der HTTP-Host abgerufen wird. Dies scheint die erwähnten Kopfeinspritzungen abzudecken. Die Prüfung gilt nur, wenn ein ;oder ,im HTTP-Host vorhanden ist, daher sollte dies in realen Systemen unkritisch sein / keine negativen Nebenwirkungen haben.
• in der cookie.phtmlFlucht wird hinzugefügt. Wenn Sie diese Datei überschreiben, muss diese also auf Ihr Thema weitergeleitet werden
• ähnlich für giftregistry/search/form.phtml

Zusammenfassend würde ich sagen, dass das Anwenden des Pflasters keine negativen Nebenwirkungen haben sollte. Denken Sie daran, die Änderungen an Ihren .phtmlDateien weiterzuleiten .

Merkwürdige Sache ist, dass der EE-Patch Änderungen an folgenden Dateien enthält:

app/code/core/Mage/Core/Controller/Request/Http.php
app/design/frontend/base/default/template/page/js/cookie.phtml

Wenn das CE nicht der Fall ist, für eine gleichwertige Version.

Ich nehme an, dass in dieser SUPEE-6482CE-Version etwas fehlt und eine V2 bald veröffentlicht werden könnte.

Magento Release Patch SUPEE-6482 zur Behebung des folgenden Problems in der CE & EE Edition

Für Magento Community Edition:

• Autoloaded File Inclusion in der Magento SOAP API
• SSRF-Sicherheitslücke in der WSDL-Datei

Für Magento Enterprise Edition

• Autoloaded File Inclusion in der Magento SOAP API
• SSRF-Sicherheitslücke in der WSDL-Datei
• Siteübergreifende Skripterstellung mit nicht validierten Headern

XSS in der Geschenklisten-Suche

Veränderung im Unterricht

• Mage_Api_Model_Server_Adapter_Soap

• Mage_Catalog_Model_Product_Api_V2

Änderungen bei Mage_Api_Model_Server_Adapter_Soap

             : $urlModel->getUrl('*/*/*');

         if ( $withAuth ) {
-            $phpAuthUser = $this->getController()->getRequest()->getServer('PHP_AUTH_USER', false);
-            $phpAuthPw = $this->getController()->getRequest()->getServer('PHP_AUTH_PW', false);
-            $scheme = $this->getController()->getRequest()->getScheme();
+            $phpAuthUser = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_USER', false));
+            $phpAuthPw = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_PW', false));
+            $scheme = rawurlencode($this->getController()->getRequest()->getScheme());

             if ($phpAuthUser && $phpAuthPw) {
                 $wsdlUrl = sprintf("%s://%s:%s@%s", $scheme, $phpAuthUser, $phpAuthPw,

Änderung bei Mage_Catalog_Model_Product_Api_V2

     public function create($type, $set, $sku, $productData, $store = null)
     {
-        if (!$type || !$set || !$sku) {
+        if (!$type || !$set || !$sku || !is_object($productData)) {
             $this->_fault('data_invalid');
         }

@@ -243,6 +243,9 @@ class Mage_Catalog_Model_Product_Api_V2 extends Mage_Catalog_Model_Product_Api
      */
     protected function _prepareDataForSave ($product, $productData)
     {
+        if (!is_object($productData)) {
+            $this->_fault('data_invalid');
+        }
         if (property_exists($productData, 'website_ids') && is_array($productData->website_ids)) {
             $product->setWebsiteIds($productData->website_ids);
         }

Weitere Informationen finden Sie unter: http://www.amitbera.com/magento-security-patch-supee-6482/

Bitte lesen Sie Magentos Dokumentation zu dieser Version. Die Antwort finden Sie hier: http://merch.docs.magento.com/ce/user_guide/Magento_Community_Edition_User_Guide.html#magento/release-notes-ce-1.9.2.1.html

Dieser Patch enthält, wie andere aktuelle Patches, zahlreiche Korrekturen für Kopien, Lizenzen und Tippfehler. Es führt auch ein paar Tippfehler von dem ein, was ich gesehen habe.

Der eigentliche Teil des Sicherheitspatches befasst sich anscheinend mit der Bereinigung von Benutzereingaben für vier verschiedene potenzielle Angriffe.