Parche de seguridad SUPEE-11086 - ¿Posibles problemas?

Magento ha lanzado un nuevo parche de seguridad para M1 y actualizaciones para M1 y M2.

Estas versiones incluyen correcciones de seguridad críticas. "Recomendamos encarecidamente que todos los comerciantes actualicen lo antes posible".

¿Qué problemas debo tener en cuenta al actualizar o aplicar este parche?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 y Open Source 1.9.4.1 contienen múltiples mejoras de seguridad que ayudan a cerrar la ejecución remota de código (RCE), las secuencias de comandos entre sitios (XSS), la falsificación de solicitudes entre sitios (CSRF) y otras vulnerabilidades.

Actualización de seguridad de Magento 2.3.1, 2.2.8 y 2.1.17

Estas versiones contienen múltiples actualizaciones funcionales y de seguridad. Riesgo: Crítico para Magento Commerce y Magento Open Source antes de 2.1.17, 2.2.8 y 2.3.1.

El mayor problema, que se encontró: Mage::log()funciona incorrectamente. Si llama a esta función con un archivo de registro personalizado (y aún no existe), el registro no se escribirá en el archivo, debido a una validación adicional, agregada en el SUPEE-11086.

Importante: el nombre del parche incluye la versión más alta a la que se aplica el parche. Entonces, un parche para 1.9.3.10 se aplicaría a 1.9.3.10, 1.9.3.9, .... a otro parche. Intentaremos mejorar los nombres en la próxima versión y también puede usar https://github.com/steverobbins/magedownload-cli, ya que debería ver los metadatos de las versiones correctamente en la API.

Como otros, tenía archivos de registro que dejaban de escribir datos por completo.

Origen del error: los archivos de registro no escriben datos

En app/Mage.phphicieron este cambio:

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

que busca en la configuración una lista separada por comas de extensiones de archivo aprobadas. Sin embargo, NO agregaron esta lista en la configuración; ni siquiera una opción en el Administrador de Mage para que podamos configurar esto por nuestra cuenta.

Solución al error: los archivos de registro no escriben datos

Para resolver esto, simplemente haga una entrada en la base de datos en la core_config_datatabla.

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

Borre también el caché de objetos y debería ver los datos escritos en los archivos de registro una vez más.

ls -lrt var/log/ | tail

Como referencia, este problema estaba en EE 1.14.2.0 con todos los parches de seguridad aplicados.

Abrí un ticket con el Soporte de Magento sobre este problema, pero aún no he recibido una respuesta de un técnico. Estoy en la cola

Lo que realmente me confunde acerca de este error es que Magento ya tiene un método para validar las extensiones de archivo de registro que agregaron a través de SUPEE-10415 a fines de 2017.

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

¿Por qué no reutilizaron esa lógica en lugar de intentar una reinvención incompleta de la rueda de troncos?

Mage::log()no puede escribir nada en los archivos de registro si no existen inicialmente. Esto se debe a la isValidfunción de Zend_Validate_File_Extensionarrojar un error no encontrado al llamar Zend_Loader::isReadable($value). He solucionado esto temporalmente moviéndome isValidal try / catch después de que se haya creado el archivo de registro y luego eliminando el archivo si falla la validación:

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

        ...
    }
}

Esta es definitivamente una solución temporal hasta que tengamos algo un poco más sólido

Posible problema con el parche 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

En el parche tenemos:

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

sin embargo, mirando el código en 1.9.3.10 (a través de mage LTS) no veo ese código en cuestión:

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

PERO, existe para 1.9.4

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

La posible razón es que falta un parche no aplicado previamente.

Intentando instalar el parche en Magento 1.9.0.1 usando PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Encontré este error

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

Lo arreglé eliminando el siguiente código de 'app / etc / config.xml' y luego volví a ejecutar el parche

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

También estoy un poco confundido sobre el nombre de los parches M1.

Para los parches más antiguos, los nombraron como SUPEE-10975 for CE 1.9.3.4-1.9.3.10o SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)pero ahora solo se trata de una versión PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

¿El parche actual aborda todas las versiones de una versión menor o solo la última?

Hice una prueba con una tienda 1.9.3.1 y todo pasó, pero no estoy muy seguro de si eso es correcto para otras versiones.

El registro se rompe en Magento 1.9. Para arreglar el inicio de sesión en el parche SUPEE-11086:

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

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

¡Espero que esto ayude!

Todos los archivos PHP nuevos en el parche para M1 tienen vars de plantilla no procesados

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

No es un problema pero parece inexacto. Tuve la misma sensación después de SUPEE-10975.

He notado un problema con los archivos de registro que ya no se crean y solo se escriben si el archivo de registro ya existe. Esto parece ser causado por la línea:

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

desde app / Mage.php. Arreglé esto usando la vieja lógica. Entonces reemplace la línea de arriba con lo siguiente:

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

comprobando la aplicación de archivo / código / core / Mage / Adminhtml / Block / Customer / Group / Edit.php Hunk # 1 FAILED at 57. 1 out of 1 hunk FAILED

En el parche 10975 hubo un error en este punto. Faltaba la declaración de devolución. Tal vez solucionó este error después de aplicar el parche 10975 o ignoró el cambio. El error se corrigió en 11086. Si esta línea de código ya ha sido ajustada / ignorada por usted, dará como resultado el error que describió al aplicar el nuevo parche. Si ya ha solucionado el error usted mismo, simplemente elimine el bloque en el archivo del parche y vuelva a ejecutar el parche.

Usando SUPEE-11086 | CE_1.9.1.0 como lo sugiere Ryan Hoerr arriba.

Aplicando SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Vie Mar 22 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

A CE_1.9.2.1

Me sale un error en cada archivo.

He aplicado el parche con éxito a otros repositorios.

Código del núcleo sin tocar.

Lista de parches aplicados

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

Problemas con el parche 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

Puede confirmar que existe un problema al intentar aplicar SUPEE-11086en una versión recién descargada y completamente parcheada de 1.9.1.1, que incluye todo, hasta el parche de gráficos del panel de administración,MPERF-10509-CE-2019-03-13-06-31-24.diff

El parche falla en los siguientes archivos.

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

Estos archivos no tienen cambios desde la confirmación inicial de la descarga v1.9.1.1. Copiar archivos de la instalación 1.9.2.4, aplicar SUPEE-11086 y luego compararlos con la fuente v1.9.4.1 confirma que ahora coinciden.

Magento v1.9.1.1 parece ser un problema un poco niño ...

Puede confirmar que existe un problema al intentar aplicar SUPEE-11086en una versión recién descargada y totalmente parcheada de 1.9.3.0, que incluye todo, hasta el parche de gráficos del panel de administración,MPERF-10509-CE-2019-03-13-06-31-24.diff

El parche falla en app / config.xml ya que falta el nodo a continuación. Agregue el nodo antes de ejecutar SUPEE-11086, sin problemas.

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

Descubrí un nuevo problema con el modelo Mage_Eav_Model_Attribute_Data_File

En la entidad de clientes, he agregado atributos de carga de archivos. Estos atributos no son obligatorios, y cuando quiero eliminar un archivo sin cargar uno nuevo, la eliminación no funciona, porque el valor del atributo no se valida a través del nuevo métodosetAttributeValidationAsPassed()

La solución rápida que he hecho está en el método validateValue($value)

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

Este problema parece estar presente en todas las versiones de Magento 1.x desde SUPEE-11086

Magento 1.9.3.1

Se produjo un problema al intentar parchear CE 1.9.3.1 usando el parche 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