Nouveau patch supee-6788 comment appliquer le patch

29

Après des semaines d'attente pour le patch aujourd'hui (27.10.2015), il a été publié: SUPEE-6788

Beaucoup de choses ont été corrigées et sont également encouragées à examiner les modules installés pour d'éventuelles vulnérabilités.

J'ouvre ce post afin d'obtenir des informations sur la façon d'appliquer le patch. Quelles sont les étapes pour appliquer le patch? À ma connaissance, voici les étapes:

  1. Correction de modules avec des fonctionnalités d'administration qui ne se trouvent pas sous l'URL d'administration
  2. Correction des modules qui utilisent des instructions SQL comme noms de champ ou champs d'échappement
  3. Blocs de liste blanche ou directives qui utilisent des variables comme {{config path=”web/unsecure/base_url”}}et{{bloc type=rss/order_new}}
  4. Traiter les exploits potentiels avec un type de fichier d'options personnalisé (aucune idée de la façon de procéder)
  5. Appliquer le patch

Est-ce la bonne procédure?

admin security patches supee-6788 lloiacono
la source
1
Versions CE répertoriées actuelles 1.7.0.0 à 1.9.2.0
Fiasco Labs
5
Le patch change .htaccess.sampleégalement .htaccess. Ce dernier est personnalisé dans la plupart des magasins, cela entraînera l'échec du correctif => Vous devez le remplacer temporairement par le fichier d'origine de Magento, appliquer le correctif, restaurer votre propre .htaccess et appliquer la modification qui protège l'accès à cron.phpmanuellement (don ' t utiliser le système de production pour ce processus bien sûr!)
Fabian Schmengler
1
qu'en est-il de ceux qui utilisent nginx?
lloiacono
4
Je vote pour clore cette question comme hors sujet car il n'y a pas de question. Veuillez déplacer les discussions vers le chat
7ochem
2
Il y a une question dans le titre même de l'article, aussi dans le dernier paragraphe je suis plus précis. Quoi qu'il en soit, ce type de message est très utile à mon avis pour centraliser les commentaires et les meilleures pratiques lors de l'application d'un correctif nouvellement publié.
lloiacono

Réponses:

33

En général, vous pouvez appliquer le patch comme tous les précédents. Jetez un œil à la documentation officielle et consultez ce post SE . Mais oui, vous devez vérifier certains points supplémentaires lors de l'application de ce patch. Byte / Hypernode a un bon article à ce sujet.

  1. Vérifiez si votre thème est personnalisé template/customer/form/register.phtmlou personnalisé template/persistent/customer/form/register.phtml. Si tel est le cas, assurez-vous qu'il comprend un form_key.
  2. Vérifiez si votre thème a une coutume layout/customer.xml. Si tel est le cas, assurez-vous d'appliquer les modifications nécessaires à partir du patch ( customer_account_resetpassworda été remplacé par customer_account_changeforgotten).
  3. Utilisez-vous des variables non standard dans les pages CMS, les blocs statiques ou les modèles de courrier électronique? Assurez-vous ensuite de les mettre sur liste blanche. Consultez cette question SE pour savoir comment mettre en liste blanche les variables / blocs.
  4. Exécutez-vous le cron.phpvia HTTP? Assurez-vous de mieux l'utiliser cron.sh. Si ce n'est pas possible, assurez-vous au moins d'appeler cron.php via CLI PHP. Si, pour une raison quelconque, vous ne pouvez pas configurer un véritable cronjob et devez l'exécuter via HTTP, consultez cette question SE
  5. Assurez-vous que toutes vos extensions utilisent le "nouveau" routage administrateur. Vous pouvez utiliser ce plugin n98-magerun pour vérifier. Vous pouvez également utiliser ce script CLI . Vous pouvez également jeter un œil à cette question SE connexe .
    1. Lorsque toutes vos extensions utilisent le routage administrateur approprié, assurez-vous de désactiver "Activer le mode de compatibilité du routage administrateur" sous Système - Configuration - Admin - Sécurité.
  6. Si vous utilisez M2ePro, mettez-le à jour vers la dernière version car les anciennes versions ne fonctionnent pas avec le nouveau patch.

Lors de la mise à jour, assurez-vous de supprimer le fichier dev/tests/functional/.htaccess. Il n'est plus présent dans Magento 1.9.2.2. Le garder signifie que vous êtes toujours vulnérable.

Dans tous les cas, vérifiez votre page avec MageReport après la mise à jour pour voir si tout s'est bien passé.

Il y a aussi un article de blog technique de Piotr , qui décrit les changements critiques.

Simon
la source
Juste une petite note, le script CLI mentionne "Vérifier que tout va bien, puis désactiver le mode de compatibilité du contrôleur d'administration". Je pense qu'ils signifient le contraire, pour l'activer. Est-ce correct?
Michael
1
@kaska Si toutes vos extensions sont correctes, vous devez désactiver le mode de compatibilité.
Simon
dans un environnement de production, ne devez-vous pas supprimer / dev complètement?
PAJ
1
@paj théoriquement oui. Mais avec la version 1.9.2.2, il est protégé par un .htaccess, donc il devrait être correct de le garder. Assurez-vous simplement de suivre mes conseils .htaccess ci-dessus.
Simon
Merci pour l'exhaustivité, ils devraient vous laisser écrire les notes de version condensées la prochaine fois! Super utile!
asherrard
3

Pour Nginx, assurez-vous de bloquer l'accès à cron.php et au dossier dev. Nous utilisons ce bloc:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }
Adam L.
la source
votre expression régulière ne fonctionnera pas, car vous vérifiez uniquement dans le répertoire,. donc "report / config.xml, cron.php" ne correspondent pas, et vous avez une barre verticale ou un symbole de tuyau à la fin .. copier-coller? ne salissez pas non plus regex avec / app /, si vous égarez quelque chose, il sera piraté.
MagenX
Mauvais travail de copier-coller, désolé. Ajouté dans le? à la fin, la barre oblique de fin est facultative. Je l'ai testé tout à l'heure et il fonctionne comme il se doit.
Adam L.
cette expression régulière est également vulnérable, vous avez ^ /, assurez-vous de ne pas copier vos fichiers source dans le dossier supérieur, comme / old /, / upgrade / etc
MagenX
@MagenX Vous dites donc que si vous n'utilisez pas le contrôle de version ou l'administration système standard BCP, que cette expression régulière est à blâmer?
Melvyn
1

Je viens d'appliquer le correctif sur ma 1.10.1 EE et cela provoque des effets secondaires sur les écrans natifs car le cœur n'est pas conforme à APPSEC-1063:

Exemple:

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

Vous pouvez trouver 2 addFieldToFilterappels non conformes à APPSEC-1063.

Cela brise les grilles Client> Attribut, vous devez donc patcher le patch, en utilisant l'astuce qu'ils recommandent dans le pdf "SUPEE-6788-Technical% 20Details% 20.pdf" dans la section APPSEC-1063

Changer le plusieurs

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

(où $ champ contient des instructions sql complexes (CASE .. WHEN THEN ...))

dans 

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

La supee-6788-toolbox et les gaiterjones de rhoerr n'ont pas détecté ce genre de problèmes, j'ai vérifié tous les autres -> addFieldToFilter ($ et aucun ne semble être à l'origine du problème.

Autres fichiers de base 1.10 affectés: (trouvés par la supee-6788-toolbox de rhoerr)

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

Il peut y en avoir plus.

ÉCRASÉ
la source