Un nuevo parche de seguridad está disponible para Magento 1, que aborda 25 problemas de APPSEC
https://magento.com/security/patches/supee-10752
¿Qué problemas comunes debe tener en cuenta al aplicar este parche?
SUPEE-10752, Magento Commerce 1.14.3.9 y Open Source 1.9.3.9 contienen múltiples mejoras de seguridad que ayudan a cerrar la ejecución autenticada de código de usuario administrador (RCE), la falsificación de solicitudes entre sitios (CSRF) y otras vulnerabilidades.
La información sobre todos los cambios en las versiones 1.14.3.9 y 1.9.3.9 está disponible en las notas de lanzamiento de Magento Commerce y Magento Open Source.
Hay parches y actualizaciones disponibles para las siguientes versiones de Magento:
Magento Commerce 1.9.0.0-1.14.3.9: SUPEE-10752 o actualice a Magento Commerce 1.14.3.9.
Magento Open Source 1.5.0.0-1.9.3.9: SUPEE-10752 o actualice a Magento Open Source 1.9.3.9.
fuente
Respuestas:
Como lo mencionan los documentos oficiales de Magento :
Los conflictos durante la instalación del parche SUPEE-10752 se producen con mayor frecuencia al tener instalada la versión 1 del parche anterior ( SUPEE-10570v1 ).
Asegúrese de quitar SUPEE-10570v1 e instale SUPEE-10570v2 antes de instalar el nuevo SUPEE-10752.
fuente
Los archivos a continuación se cambian / crean después de aplicar el parche
Para EE Edition, los archivos a continuación se agregan además de CE
Cualquiera anula el archivo onepage.php, actualice el archivo.
Para la validación de clave agregada, verifique que su formulario de carrito tenga clave de formulario
cron.php: identificador de excepción en el archivo cron.php
GD2: devuelve el tipo mime real.
Si usa nginx en lugar de Apache, asegúrese de actualizar su configuración para duplicar este cambio.
El método de envío de los archivos recién agregados / actualizados son:
Escapehtml archivos:
Archivos frontend de productos descargables: cualquier persona que use productos descargables, actualice los archivos en sus archivos de tema.
Código de verificación
Reemplazar con
Código de verificación
Reemplazar con
Código de verificación
Reemplazar con
Código de verificación
Reemplazar con
Reemplazar con
Reemplazar con
Código de verificación
Reemplazar con
Código de verificación
Reemplazar con
Otros archivos de Escapehtml:
fuente
La modificación del
filter
método sobrecargado enZend_Filter_PregReplace
es ingenua y supone que$this->_matchPattern
siempre es una cadena. Esta propiedad se proporciona posteriormente como el primer argumento parapreg_replace
. En realidad, una matriz también es un argumento perfectamente válido. Este hecho es realmente utilizado por múltiplesZend_Filter
clases principales (comoZend_Filter_Word_SeparatorToCamelCase
). Entonces, cualquier extensión / rama de código que use este filtro o uno de sus derivados, con un argumento de matriz para_matchPattern
, comenzará a arrojarseWarning: substr() expects parameter 1 to be a string, array given
.Un crudo ejemplo de lo que probablemente debería hacer sería algo similar a:
Aunque todavía no he hecho ninguna prueba exhaustiva de esto.
EDITAR: Vale la pena señalar que, si bien la solución propuesta anteriormente debe evitar los errores, la implementación es técnicamente un poco ingenua y propensa a falsos positivos. Se supone que el delimitador de expresiones regulares que separa el patrón de los modificadores es el mismo que al principio de la cadena. Técnicamente, este no tiene que ser el caso, ya que PHP admite varios delimitadores de estilo de soporte. Por lo tanto, la entrada válida
{hello}is
determinará los modificadores que sonhello}is
(en lugar de los modificadores reales deis
) y, por lo tanto, arrojará una excepción, aunque el patrón no incluya realmente ele
modificador.fuente
1.7.0.2 Problema de versión: después de instalar el parche y pasar a la página de pago (pago genérico de Magento), obtenga este error
Error de análisis: error de sintaxis, inesperado
Al invertir el parche, el error desaparece.
Al profundizar en esta pregunta, descubrí que el parche ha agregado la siguiente línea al archivo onepage.php.
SOLUCIÓN: Gracias a @FabianSchmengler
¡ACTUALIZACIÓN A PHP versión 5.4 y superior!
fuente
problema conocido :-
Si su código o extensión personalizada está usando
Zend/Filter/PregReplace.ph
p con el modificador e, ahora devolverá un error debido a posibles problemas de RCE.Este parche sigue por debajo de la seguridad.
+++ app/code/core/Mage/Admin/Model/User.php
y entonces
class Mage_Admin_Model_User
app/code/core/Mage/Adminhtml/Block/Catalog/Product/Composite/Fieldset/Options.php
app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Options/Option.php app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Options/Option.php
app/code/core/Mage/Catalog/Model/Product.php
+++ app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Datetime.php
app/design/frontend/base/default/template/downloadable/catalog/product/links.phtml
app/design/frontend/base/default/template/downloadable/checkout/cart/item/default.phtml
app/design/frontend/base/default/template/downloadable/checkout/onepage/review/item.phtml
app/design/frontend/base/default/template/downloadable/sales/order/items/renderer/downloadable.phtml
app/design/frontend/default/iphone/template/downloadable/checkout/onepage/review/item.phtml
app/design/frontend/rwd/default/template/downloadable/checkout/cart/item/default.phtml
app/design/frontend/rwd/default/template/downloadable/checkout/onepage/review/item.phtml
app/design/frontend/rwd/default/template/downloadable/sales/order/items/renderer/downloadable.phtml
app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Mage_Adminhtml_Model_LayoutUpdate_Validator
Mage_Adminhtml_Model_LayoutUpdate_Validator
app/code/core/Mage/Catalog/Model/Resource/Category/Tree.php
app/code/core/Mage/Adminhtml/controllers/Catalog/CategoryController
app/code/core/Mage/Adminhtml/controllers/Cms/WysiwygController.php
lib/Varien/Image/Adapter/Gd2.php
app/code/core/Mage/Checkout/Model/Api/Resource/Customer.php
app/code/core/Mage/Checkout/Model/Type/Onepage.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
Mage_Customer_AccountController
``
app/code/core/Mage/Log/Model/Visitor.php
app/code/core/Mage/Usa/Helper/Data.php
Archivos AGREGADOS para UPS
Configuración agregada para esta nueva funcionalidad
app/code/core/Mage/Usa/etc/system.xml
Línea 843
886
app/design/adminhtml/default/default/template/system/shipping/ups.phtml
1> 1) Paquete de validación de producto
app/design/adminhtml/default/default/template/bundle/product/edit/bundle/option.phtml
fuente
Parece que parte del parche es htmlEscaping all "getLinksTitle ()". Pero olvidaron los siguientes archivos (esto se basa en 1.8.1).
fuente
El parche no funciona en vainilla Magento CE 1.8.0.0
Actualización: solución agregada a continuación.
Problema:
Parches anteriores aplicados:
Solución
Se corrigió editando el archivo de parche. Reemplazado el parche
downloadable.phtml
por el del parchev1.7.0.2
en el archivo de parche original, estas son las líneas 1854-1862.Esto se debe principalmente a la sangría en el archivo. Como los cambios para
downloadable.phtml
adentroV1.7.0.2
tienen más sangría.Solución 2
Tuve un problema similar, pero pude solucionarlo volviendo a guardar el archivo original en un editor que obligaba a que la línea terminara en LF de estilo Unix, no en CRLF de estilo de Windows o Mac CR.
fuente
En referencia a Matt Antley, tal vez no incluyeron SUPEE-10570v2 debido a esto
Por lo que sé, el error de pago no era muy común, por lo que decidieron quedarse con SUPEE-10570, que protege contra los dos problemas de seguridad de bajo riesgo.
fuente
SUPEE-10570v2
, tendrán que volver a aplicarlo.SUPEE-10752
y arrojé un poco el arma. Una vez más, gracias por los comentarios.El parche no funciona en Magento CE 1.6.0.0 de vainilla
Actualización: solución agregada a continuación.
Problemas:
Parches anteriores aplicados:
Resuelto
He solucionado este problema cambiando el archivo de revisión. Reemplacé los trozos que daban los problemas por los correspondientes del parche para v1.5.1.0. En el archivo de parche original, estas son las líneas 167-177 y 663-670.
fuente
En EE v1.14.2.4 después de aplicar SUPEE-10752, también tuve que aplicar el siguiente parche para solucionar el problema por el que el pago redirige a la página de inicio en lugar de a la página de éxito:
Archivo: invalid_session_fix-2018-03-14-05-10-19.patch
La solución anterior se encuentra en https://magento.com/tech-resources/download en SUPEE-10570 > invalid_session_fix.patch (0 MB)
fuente
He encontrado un problema después de este parche. No puedo establecer el "Método libre" para "Tipo de UPS" "United Parcel Service XML". Magento arroja un error cuando se selecciona cualquier método en el menú desplegable "Método libre". Error: " Campo" Método libre Ups "tiene un valor incorrecto. "
¿Alguien ha enfrentado el mismo problema y obtuvo la solución?
¡Gracias por adelantado!
fuente
En 1.6, el parche ups.phtml está roto. Está haciendo referencia a $ SavedOriginShipment, $ SavedFreeShipment que tienen un error tipográfico en 1.6 ($ stroredOriginShipment y $ stroredFreeShipment). Además, hace referencia a $ sharedUpsType que no existe en absoluto en 1.6.
fuente
Hemos encontrado un problema en 1.9.1.0 y 1.9.2.4 (no lo he probado en otros). No aparece en todos nuestros proyectos, pero se ha repetido en varios de ellos. Creemos que podría estar afectando los proyectos que tenían instalado SUPEE-10570v1 en algún momento.
Después de aplicar el parche, si un usuario inicia sesión, verá su página de cuenta perfectamente bien. Sin embargo, si intentan volver a cualquier otra página del sitio, la página dejará de responder y verán una pantalla en blanco o una 502 Bad Gateway. Esto se debe a que PHP entra en un bucle infinito y se segfaula o se detiene por la configuración de .ini.
Me las he arreglado para desenterrar el problema de que es un bucle infinito en la línea que carga el
$customer
en\app\code\core\Mage\Customer\Helper\Data.php
,getPasswordTimestamp()
.Al mirar el rastro de la pila de la recursión infinita, se repite una y otra vez. De alguna manera, parece que
->load()
termina llamando algetPasswordTimestamp()
método.La solución provista en /magento//a/235984/67252 funciona bien, pero me gustaría saber qué está sucediendo.
fuente
Después de aplicar el parche SUPEE 10752, Registrarse y finalizar la compra lleva la página de éxito a la página de inicio. ¿Alguna sugerencia?
fuente
Vimos una página en blanco en / checkout / * después de aplicar SUPEE-10752 y compilar
versión: 1.9.1.0
Condiciones de activación: aplicar SUPEE-10752 + habilitar el compilador + iniciar sesión como cliente, luego visitar / pagar / *
Solo para aclarar: con el compilador desactivado, todo salió bien, con el compilador activado solo pudimos ver una página de carrito en blanco cuando iniciamos sesión sin ninguna entrada de registro (incluso después de activar todos los registros posibles y el modo de desarrollador).
fuente