Parche de seguridad Magento SUPEE-6482, ¿Qué está parcheado?

Hoy, 04.08.2015 se lanzó un nuevo parche de seguridad, algunos colegas y yo estábamos revisando el parche, y siempre es bueno tener una discusión sobre lo que cambió, ¿alguien sabe cuáles son los posibles ataques que podrían afectar y la tienda sin parchear? ¿Que es lo peor que puede pasar?

Actualización: solo quería agregar el correo electrónico que Magento envió hoy para completar la publicación.

El parche de seguridad real ( SUPEE-6482 ) solo afecta a los dos archivos siguientes y es un parche de API.

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

La instalación completa de 1.9.2.1 es completamente diferente. Diferiría el código fuente entre 1.9.2.0 y 1.9.2.1 para descubrir los otros dos elementos que fueron parcheados.

Las notas de la versión son para el instalador completo, debe verificar el parche para ver si realmente incluye todos los elementos indicados en las notas de la versión.

Implicaciones de ejecutar un servidor sin parchear:

1. Secuencias de comandos entre sitios utilizando encabezados no validados => Envenenamiento de caché
2. Inclusión de archivos con carga automática en Magento SOAP API => Carga automática de código remoto
3. XSS en Gift Registry Search => Robo de cookies y suplantación de usuario
4. Vulnerabilidad de SSRF en el archivo WSDL => Fuga interna de información del servidor e inclusión remota de archivos

NOTA: Archivos parcheados en el archivo de instalación completa que no están parcheados con el parche, ¿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()) ?>';

Eché un vistazo a los cambios en detalle y qué efectos secundarios son de esperar.

En la versión para EE 1.13.1.0, los siguientes archivos cambiaron:

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

• En Adapter/Soap.php, se agrega urlencoding a los datos de autenticación. Esto no debería tener efectos secundarios negativos. Asegura que el resultado wsdlUrlsea ​​válido. Sin este cambio, uno podría influir en la URL
• Product/Api/V2.php: Aquí hay algunas comprobaciones si los datos pasados ​​son un objeto. Esto no debería suceder en circunstancias normales.
• en Request/Http.phpy PageCache/Model/Processor.phpse agrega una verificación al obtener el HOST HTTP. Esto parece cubrir las inyecciones de encabezado mencionadas. La verificación solo se aplica si hay un ;o ,en el host HTTP, por lo que esto no debería ser crítico en los sistemas de la vida real / no tener efectos secundarios negativos.
• en la cookie.phtmlfuga se agrega. Por lo tanto, esto debe ser transferido a su tema si sobrescribe ese archivo
• similar para giftregistry/search/form.phtml

Para resumir, diría que aplicar el parche no debería tener ningún efecto secundario negativo. Recuerde reenviar el puerto de los cambios a sus .phtmlarchivos.

Lo extraño es que el parche EE contiene modificaciones en los siguientes archivos:

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

Cuando el CE no lo hace, para una versión equivalente.

Supongo que falta algo en esa SUPEE-6482versión CE, y un V2 podría lanzarse pronto.

Parche de lanzamiento Magento SUPEE-6482 para corregir el problema a continuación en la edición CE y EE

Para Magento Community Edition:

• Inclusión automática de archivos en la API SOAP de Magento
• Vulnerabilidad de SSRF en el archivo WSDL

Para Magento Enterprise Edition

• Inclusión automática de archivos en la API SOAP de Magento
• Vulnerabilidad de SSRF en el archivo WSDL
• Secuencias de comandos entre sitios utilizando encabezados no validados

XSS en la búsqueda del registro de regalos

Haciendo cambio en clase

• Mage_Api_Model_Server_Adapter_Soap

• Mage_Catalog_Model_Product_Api_V2

Cambios en 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,

cambiar en 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);
         }

Ver más en: http://www.amitbera.com/magento-security-patch-supee-6482/

Lea la documentación de Magento en este lanzamiento, la respuesta está allí: http://merch.docs.magento.com/ce/user_guide/Magento_Community_Edition_User_Guide.html#magento/release-notes-ce-1.9.2.1.html

Este parche, como otros parches recientes, contiene muchas correcciones de copia, licencia y error tipográfico. También presenta algunos errores tipográficos de lo que he visto.

La parte del parche de seguridad real parece abordar la desinfección de entrada del usuario para 4 posibles ataques diferentes.