Nuevo parche supee-6788 como aplicar el parche

29

Después de semanas de esperar el parche hoy (27.10.2015), se lanzó: SUPEE-6788

Se repararon muchas cosas y también se recomienda revisar los módulos instalados para detectar posibles vulnerabilidades.

Abro esta publicación para obtener algunas ideas sobre cómo aplicar el parche. ¿Cuáles son los pasos para aplicar el parche? A mi entender, estos son los pasos:

Arreglar módulos con funcionalidad de administrador que no está bajo la URL de administrador
Arreglar módulos que usan sentencias SQL como nombres de campo o campos de escape
Lista blanca de bloques o directivas que usan variables como {{config path=”web/unsecure/base_url”}}y{{bloc type=rss/order_new}}
Abordar posibles vulnerabilidades con el tipo de archivo de opción personalizada (no tengo idea de cómo hacerlo)
Aplique el parche

¿Es este el procedimiento correcto?

— lloiacono
fuente

1

Versiones actuales de la CE incluidas en la lista 1.7.0.0 a 1.9.2.0

— Fiasco Labs

55

El parche cambia .htaccess.sampletan bien como .htaccess. Este último está personalizado en la mayoría de las tiendas, esto hará que el parche falle => Debe reemplazarlo temporalmente con el archivo original de Magento, aplicar el parche, restaurar su propio .htaccess y aplicar el cambio que protege el acceso cron.phpmanualmente (no ' ¡No use el sistema de producción para este proceso, por supuesto!)

— Fabian Schmengler

1

¿Qué pasa con los que usan nginx?

— lloiacono

44

Estoy votando para cerrar esta pregunta como fuera de tema porque no hay duda. Por favor mueva las discusiones al chat

— 7ochem

2

Hay una pregunta en el título de la publicación, también en el último párrafo soy más específico. Independientemente de esto, este tipo de publicación es muy útil en mi opinión para centralizar los comentarios y las mejores prácticas al aplicar un parche recién lanzado.

— lloiacono

33

En general, puede aplicar el parche como todos los anteriores. Echa un vistazo a la documentación oficial y mira esta publicación SE . Pero sí, hay algunos puntos adicionales que debe verificar al aplicar este parche. Byte / Hypernode tiene una buena publicación al respecto.

Comprueba si tu tema tiene una costumbre template/customer/form/register.phtmlo una costumbre template/persistent/customer/form/register.phtml. Si este es el caso, asegúrese de que incluya a form_key.
Comprueba si tu tema tiene una costumbre layout/customer.xml. Si este es el caso, asegúrese de aplicar los cambios necesarios desde el parche ( customer_account_resetpasswordse ha cambiado a customer_account_changeforgotten).
¿Utiliza variables no estándar en páginas CMS, bloques estáticos o plantillas de correo electrónico? Luego, asegúrese de incluirlos en la lista blanca. Vea esta pregunta SE para aprender a incluir en la lista blanca variables / bloques.
¿Ejecutas el cron.phpvía HTTP? Asegúrate de usarlo mejor cron.sh. Si esto no es posible, al menos asegúrese de llamar a cron.php a través de CLI PHP. Si por alguna razón no puede configurar un cronjob real y necesita ejecutarlo a través de HTTP, vea esta pregunta SE
Asegúrese de que todas sus extensiones utilicen la "nueva" ruta de administrador. Puede usar este complemento n98-magerun para verificar. También puede usar este script CLI . También puede echar un vistazo a esta pregunta SE relacionada .
1. Cuando todas sus extensiones utilicen el enrutamiento de administrador adecuado, asegúrese de desactivar "Habilitar el modo de compatibilidad de enrutamiento de administrador" en Sistema - Configuración - Administrador - Seguridad.
Si usa M2ePro, actualícelo a la última versión ya que las versiones anteriores no funcionan con el nuevo parche.

Al actualizar, asegúrese de eliminar el archivo dev/tests/functional/.htaccess. Ya no está presente en Magento 1.9.2.2. Mantenerlo significa que aún eres vulnerable.

En cualquier caso, revise su página con MageReport después de actualizar para ver si todo salió bien

También hay una publicación técnica en el blog de Piotr , que describe los cambios críticos.

— Simon
fuente

Solo una pequeña nota, el script de la CLI menciona 'Verifique que todo esté bien, luego desactive el modo de compatibilidad del controlador de administrador'. Creo que significan lo contrario, para habilitarlo. ¿Está bien?

— Michael

1

@kaska Si todas sus extensiones están bien, debe desactivar el modo de compatibilidad.

— Simon

en un entorno de producción, ¿no deberías eliminar / dev completamente?

— paj

1

@paj teóricamente sí. Pero con la versión 1.9.2.2, está protegido con un .htaccess, por lo que debería estar bien mantenerlo. Solo asegúrate de seguir mi consejo de .htaccess arriba.

— Simon

Gracias por lo completo, ¡deberían permitirte escribir las notas de lanzamiento condensadas la próxima vez! Super útil!

— asherrard

6

Hay un archivo de verificación que lo ayuda a identificar problemas: https://github.com/gaiterjones/magento-appsec-file-check

Hice un script CLI con él. https://github.com/Schrank/magento-appsec-file-check

— Fabian Blechschmidt
fuente

3

Para Nginx, asegúrese de bloquear el acceso a cron.php y la carpeta de desarrollo. Usamos este bloque:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

— Adam L.
fuente

su expresión regular no funcionará, porque verifica solo en el directorio,. entonces "report / config.xml, cron.php" no coincide, y tiene una barra vertical o un símbolo de tubería al final ... ¿copiar y pegar? tampoco ensucies regex junto con / app /, si extravías algo, será pirateado.

— MagenX

Mal trabajo de copiar y pegar, lo siento. Añadido en el? al final, por lo que la barra inclinada final es opcional. Lo probé hace un momento y funciona como debería.

— Adam L.

también esta expresión regular es vulnerable, tienes ^ /, asegúrate de no copiar tus archivos fuente en la carpeta superior, como / old /, / upgrade / etc

— MagenX

@MagenX ¿Entonces está diciendo que si no usa el control de versiones o el BCP de administración del sistema estándar, es culpa de esta expresión regular?

— Melvyn

1

Acabo de aplicar el parche en mi EE 1.10.1 y esto causa efectos secundarios en las pantallas nativas porque el núcleo no es compatible con APPSEC-1063:

Ejemplo:

En app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Puede encontrar 2 addFieldToFilterllamadas que no cumplen con APPSEC-1063.

Esto está rompiendo las cuadrículas Cliente> Atributo, por lo que debe parchear el parche, utilizando el truco que recomiendan en el pdf "SUPEE-6788-Technical% 20Details% 20.pdf" en la sección APPSEC-1063

Cambiando los varios

    $this->addFieldToFilter($field, 0);

(donde $ field contiene complejas (CASO ... CUANDO ENTONCES ...) sentencias sql)

dentro

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Tanto el supee-6788-toolbox de rhoerr como los gaiterjones 'no detectaron este tipo de problemas, verifiqué todos los demás -> addFieldToFilter ($ y ninguno parece estar causando el problema.

Otros archivos principales 1.10 afectados: (encontrado por rhoerr's supee-6788-toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php

Puede haber más.

— COLOCADO
fuente