Parche de seguridad SUPEE-11086 - ¿Posibles problemas?

24

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.

Ryan Hoerr
fuente
Ryan Hoerr, supongo que debes crear una pregunta diferente para Magento 2.3.1, 2.2.8 y 2.1.17 Actualización de seguridad
Amit Bera
2
¿Alguna idea de por qué no hay una versión para 1.8.0 / 1.8.1?
Jason

Respuestas:

20

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.

Un espectador
fuente
Este problema también se aplica a Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
Aad Mathijssen
55
Todos mis registros se detuvieron por completo. Incluso el sistema y los registros de excepciones. ¿Hay alguna solución para esto?
Kalvin Klien
todos mis archivos de registro escritos por Mage :: log también se han detenido. M1 EE 1.14.0.2
PromInc
la única solución es devolver el código deMage::log()
Aswerer
3
A partir del 25 de junio, Magento ha lanzado SUPEE-11155, Magento Commerce 1.14.4.2 y Magento Open Source 1.9.4.2 que incluyen una solución para el Mage::log()método.
Aad Mathijssen
11

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.

Piotr Kaminski
fuente
5

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?

PromInc
fuente
3
Esto no es correcto. En app / etc / config.xml allowFileExtensions se ha agregado como configuración. Si no existe en la base de datos, se utilizará. El problema real es que la nueva función de validación primero intenta ver si el archivo ya existe, lo cual podría no ser así.
René Schep
Gracias por señalar eso @ RenéSchep Veo ese cambio en el parche ahora. Mirando más profundo, mi archivo config.xml vive en un repositorio diferente al resto de nuestra base de código. Por esa razón, cuando presioné el cambio para este parche, el archivo de configuración no se actualizó con este cambio. En cuanto a no escribir en archivos inexistentes, personalmente encuentro que funciona en mis servidores. Me hace preguntarme si este es un problema de permisos de carpeta en el propio sistema de archivos. Sin embargo, no he profundizado demasiado en ese código.
PromInc
De lo que he probado es que funciona si el archivo ya existe. La primera comprobación que hace Valid es verificar si el archivo es legible. Si no existe, no se intenta crear el archivo y se devuelve un falso.
René Schep
@ RenéSchep, ¿cómo lo solucionamos? El soporte de Magento es dolor en la a ** h. Son muy lentos en responder.
Adarsh ​​Khatri
@AdarshKhatri necesita crear el archivo antes de que Magento pueda escribirle. toque /path/to/magento/install/html/var/log/newlogfile.log
PromInc
4

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

Daniel Doyle
fuente
3

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.

ProxiBlue
fuente
44
Te estás perdiendo el parche SUPEE-10975.
Richard Feraro
mmm, de acuerdo con mis conjuntos de parches, eso ya está aplicado: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Jue 8 nov 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue
El nombre de archivo del último parche es PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh, mientras que el suyo parece haberse emitido el pasado 8 de noviembre de 2018, que no es el último, supongo.
Richard Feraro
1
Revertí PATCH_SUPEE-10975 y volví a aplicar, luego volví a aplicar lo último, todo funcionó
ProxiBlue
Este fue un error en SUPEE-10975 que hizo que no pudieras eliminar Grupos de clientes. Parece que lo arregló manualmente, lo que hace que este nuevo parche falle, lo que también lo soluciona.
René Schep
3

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>
rupi
fuente
3

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.

Sebastian
fuente
Gracias Ryan! Eso también responde a la pregunta de @jason "¿Alguna idea de por qué no hay una versión para 1.8.0 / 1.8.1?" Para eso debería ir con el parche 1.7.0.2, ¿verdad? No sabía que había parches que abordaban múltiples lanzamientos menores antes.
Sebastian
2
¿Estás seguro @RyanHoerr? ¿No es lo contrario, como se presume en otro hilo magento.stackexchange.com/questions/267576/… ? Parece que, si adivinamos por el antiguo estilo de nomenclatura, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh podría aplicarse desde 1.7.0.0 a 1.7.0.2, y así, el El número de versión en cada parche sería el último en ese caso. ¿Alguien de Magento podría confirmar cuál es la lógica detrás de ese nuevo estilo de nombres, por favor? Gracias de antemano ..
Antoine Kociuba
2
Iré con @AntoineKociuba Con 2 tiendas 1.8.1 diferentes que me encuentro con 4 fallas con el parche 1.7.0.2: - app / code / core / Mage / Usa / etc / system.xml Hunk # 4 FAILED at 845 - app /etc/config.xml Hunk # 1 FALLÓ en 144 - app / locale / en_US / Mage_Widget.csv Hunk # 1 FALLÓ en 6 - lib / Varien / Filter / Template.php Hunk # 2 FALLÓ en 254 mientras que el 1.9.1.0 funciona suavemente. Lo mismo con una tienda 1.9.3.1: el parche 1.9.2.4 no funciona mientras que el 1.9.3.10 lo hace.
Sebastián
3
@RyanHoerr esto es incorrecto. El nombre incluye la última versión a la que se aplica un 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 github.com/steverobbins/magedownload-cli, ya que debería ver los metadatos de las versiones correctamente en la API.
Piotr Kaminski
Se eliminó mi mala información. Gracias por la corrección.
Ryan Hoerr
2

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!

Mike Dubs
fuente
1

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.

Mikhail Chelevich
fuente
1

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)) {
rupi
fuente
0

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.

Magento Sharingan
fuente
1
Tuve que revertir el parche "menos oficial" SUPEE-11043 para que funcione SUPEE-11086
Jeroen Vermeulen - MageHost
0

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
Bevan Holman
fuente
Gracias @AntoineKociuba por la aclaración. He verificado que todos los parches anteriores han sido correctos, pero cuando aplico el parche correcto como se indica a continuación PATCH_SUPEE-11086_CE_1.9.2.4_v1 para mi instalación 1.9.2.1, sigo recibiendo un error en todos menos un trozo. ¿Sugeriría un parche manual?
Bevan Holman
¿En qué pedazo estás fallando?
René Schep
Esto se resolvió, tuve que obtener un nuevo clon del repositorio. Gracias René
Bevan Holman
0

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
Roy Toledo
fuente
Al ver como app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php falló. Supongo que aplicó el parche SUPEE-11043 que SUPEE-11086 supone que no ha hecho.
René Schep
0

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

Manzana dulce
fuente
Acabo de comparar el parche 1.9.2.4 con el parche 1.9.1.0. Y parece que la diferencia entre estos parches son los 3 archivos que mencionas. Parece que el parche 1.9.1.0 debería usarse en 1.9.1.1.
René Schep
0

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>
Manzana dulce
fuente
0

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

Laurent Tastet
fuente
0

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
Aditya Putra
fuente