Zend Framework concerné par une faille d’exécution de code

0

Les versions du populaire outil de développement Zend Framework et de son successeur Laminas Project peuvent être utilisées de manière abusive par un attaquant pour exécuter du code à distance sur des sites Web qui utilisent PHP et des applications Web vulnérables aux attaques.

Cependant, les développeurs de Zend Framework soulignent que les conditions dans lesquelles une application Web peut être utilisée de manière abusive exigent d’abord que l’auteur de l’application écrive un code «intrinsèquement non sécurisé». Pour cette raison, les responsables actuels de Zend Framework contestent la classification de la vulnérabilité.

«Nous contestons la vulnérabilité et considérons notre correctif comme un correctif de renforcement de la sécurité, et non comme un correctif de vulnérabilité», a déclaré Matthew Weier O’Phinney, propriétaire du produit Zend et ingénieur principal dans une interview.

Les versions impactées de Zend Framework

Les versions concernées sont la version 3.0.0 de Zend Framework et les versions antérieures à la version 2.14.2 du laminas-http de Laminas Project, avec une estimation de «plusieurs millions de sites Web» utilisant le framework et éventuellement impactés. Les nouveaux responsables de Zend Framework, Laminas Project, font partie de l’écosystème collaboratif open source de la Linux Foundation.

zend framework

La faille a été divulguée publiquement la semaine dernière par le chercheur en cybersécurité Ling Yizhou, qui a également publié deux scénarios d’attaque de preuve de concept. La faille, identifiée comme CVE-2021-3007, n’a pas de score de gravité répertorié avec MITRE. Cependant, elle est classée «à haut risque» par d’autres membres de la communauté de la cybersécurité.

La fin de vie de Zend Framework était le 31 décembre 2019, après quoi il a été intégré au projet Laminas. Selon les responsables, Zend Framework et Laminas Project sont équivalents.

«Le projet est un ensemble de composants individuels, chacun versionné séparément. En tant que tel, «3.0» fait référence à une poignée de composants de base qui ont été étiquetés avec des sorties de la version 3, dont beaucoup ont considérablement évolué depuis », a déclaré O’Phinney.

La désérialisation des vulnérabilités et les scénarios d’attaques

Selon Yizhou, la version 3.0.0 de Zend Framework a une vulnérabilité de désérialisation qui peut conduire à l’exécution de code à distance «si le contenu est contrôlable, lié à la méthode __destruct de la classe Zend\Http\Response\Stream dans Stream.php.

Des scénarios d’attaque de preuve de concept contre Zend Framework et Laminas Project ont été publiés sur une page GitHub maintenue par le chercheur en sécurité Yizhou. Des détails supplémentaires sur la mitigation se trouvent sur la page du projet Lamina, également hébergée sur GitHub.

zend framework laminas project

Une vulnérabilité de désérialisation (a.k.a désérialisation non sécurisée) se produit lorsque des données contrôlables par l’utilisateur sont désérialisées par un site Web. En d’autres termes, lorsqu’un site Web permet à un utilisateur d’introduire des données non fiables ou d’effectuer une injection d’objets dans une application Web. Les données injectées peuvent abuser de la logique d’une application et déclencher une attaque par déni de service ou permettre à un attaquant d’exécuter du code arbitraire lorsque les données sont désérialisées.

La désérialisation et la sérialisation sont des termes techniques décrivant le processus de transformation d’un objet (code) en un format de données (sérialisation) qui peut être restauré plus tard (désérialisation). «Les gens sérialisent souvent les objets afin de les enregistrer dans le stockage ou pour les envoyer dans le cadre de communications», décrit OWASP.

La vulnérabilité est liée à la «méthode __destruct» dans la classe «\Http\Response\Stream de Zend Framework dans Stream.php».

Une classification de la vulnérabilité disputée

Le projet Laminas de la Fondation Linux conteste la classification CVE. Dans une déclaration publiée sur sa page GitHub, ils ont déclaré:

«Après examen, nous pensons qu’il ne s’agit pas d’une vulnérabilité spécifique au framework, mais plutôt plus généralement au langage. Les fonctions un/serialize() ont une longue histoire de vulnérabilités (veuillez consulter https://www.google.com/search?q=php+unserialize+RCE par exemple), et les développeurs ne doivent JAMAIS les utiliser sur des entrées non fiables. Si cela est impossible, ils doivent au moins passer le deuxième argument $options, et fournir une liste des classes autorisées, ou utiliser l’argument pour interdire toute désérialisation d’objets (voir https://www.php.net/ désérialiser pour plus de détails).

Nous avons également reçu le rapport que vous avez fourni contre Zend Framework. Ce projet n’est plus actif et tous les problèmes de sécurité sont maintenant résolus dans Laminas Project (qui obligera les utilisateurs à migrer vers Laminas depuis Zend Framework). Nos résultats restent cependant les mêmes pour ce projet; il s’agit d’un problème de langage PHP et non spécifique à notre projet. »

Il a ajouté que la classification est plus généralement comprise comme une «injection d’objet PHP» et n’est pas spécifique à un cadre donné.

«Quoi qu’il en soit, nous fournissons ce correctif pour aider à mieux protéger nos utilisateurs de ces scénarios. Le correctif fournit une vérification de type de la propriété $streamName avant d’effectuer une opération de nettoyage (qui aboutit à une opération unlink(), qui, auparavant, aurait pu entraîner un appel implicite à la méthode __toString() d’un objet) dans le destructeur Laminas\Http\Response\Stream», explique le communiqué.

Si cet article vous a plu, jetez un œil notre article précédent.

Laisser un commentaire