El 13 de enero llegaba un email advirtiendo sobre problemas detectados en la librería de mail de Zend Framework.
El aviso en cuestión era:
La vulnerabilidad, ZF2016-04, fue explicada por Zend. Por su parte, nos prometió un parche y, hoy 7 de febrero se hizo público.
El mail/formalismo en cuestión:
¿Qué implica el parche para nos los mortales que demos lidiar y/u ocuparnos de las tiendas?. Por suerte su aplicación parece no ser tan grave.
Lo primero a tener en cuenta: TODAS las ediciones suben de versión.
Magento 1
Para actualizar la rama 1.x, tenemos dos opciones:
- Descargar el parche (aquí hay algún detalle de cómo hacerlo o como siempre lo encontramos en algún lugar de [la página de descargas).
- Bajar por completo la versión 1.9.3.2 de Magento y pisar los archivos (suponiendo que siendo 2017 no han tocado el core).
En caso de usar el parche, como siempre hacíamos, bajamos una copia del archivo en la raíz de nuestra tienda y luego ejecutamos:
SH PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.shCuando termina, si todo estuvo bien deberíamos ver este output:
PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 14: PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 127: not found
PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 14: PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 127: not found
PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 25: PATCH_SUPEE-9652_v2-2017-02-07-01-18-38.sh: 0: not found
Checking if patch can be applied/reverted successfully...
Patch was applied/reverted successfully.Al hacer un git status, el resultado fue que el archivo modificado por el parche es:
lib/Zend/Mail/Transport/Sendmail.phpY si hacemos un git diff del archivo vemos que los cambios son:
diff --git a/lib/Zend/Mail/Transport/Sendmail.php b/lib/Zend/Mail/Transport/Sendmail.php
index b24026b..9323f58 100644
--- a/lib/Zend/Mail/Transport/Sendmail.php
+++ b/lib/Zend/Mail/Transport/Sendmail.php
@@ -119,14 +119,19 @@ class Zend_Mail_Transport_Sendmail extends Zend_Mail_Transport_Abstract
);
}
- set_error_handler(array($this, '_handleMailErrors'));
- $result = mail(
- $this->recipients,
- $this->_mail->getSubject(),
- $this->body,
- $this->header,
- $this->parameters);
- restore_error_handler();
+ // Sanitize the From header
+ if (!Zend_Validate::is(str_replace(' ', '', $this->parameters), 'EmailAddress')) {
+ throw new Zend_Mail_Transport_Exception('Potential code injection in From header');
+ } else {
+ set_error_handler(array($this, '_handleMailErrors'));
+ $result = mail(
+ $this->recipients,
+ $this->_mail->getSubject(),
+ $this->body,
+ $this->header,
+ $this->parameters);
+ restore_error_handler();
+ }
}
if ($this->_errstr !== null || !$result) {Luego de probar la tienda, todo parece estar en condiciones.
La segunda forma, más radical, es la de pisar todos los archivos core. El upgrade funcionó perfectamente.
Lo que si, además de la modificación por el parche, si hacemos un status veremos que hay infinidad de archivos modificados. ¿El motivo?
- * @copyright Copyright (c) 2006-2016 X.commerce, Inc. and affiliates (http://www.magento.com)
+ * @copyright Copyright (c) 2006-2017 X.commerce, Inc. and affiliates (http://www.magento.com)Actualización del copyright en los archivos.
Los detalles completos en el changelog.
Magento 2
Si bien la vulnerabilidad está presente también, las actualizaciones incluyen varias correcciones y mejoras, además del parche. Aquí el changelog para la versión CE y el de la versión EE.
Por suerte, aquí, Composer.
Si estás en Magento 2.0.x, acutalizamos con:
composer require magento/product-community-edition 2.0.12 --no-updateSeguimos con:
composer updateY para finalizar, validamos la versión que nos ha quedado:
bin/magento --version
Magento CLI version 2.0.12Todo correcto.
Ahora para 2.1.x CE, cambiamos el primer paso por:
composer require magento/product-community-edition 2.1.4 --no-updateLuego repetimos los dos pasos siguientes. Si se trata de versión Enteprise, el primer paso sería:
composer require magento/product-enterprise-edition 2.0.12 --no-updatecomposer require magento/product-enterprise-edition 2.1.4 --no-updateY no mucho más.