Après un an sans faille, Symfony a dévoilé ce 6 novembre 2024 sur son blog huit vulnérabilités d’un coup. Elles affectent différentes versions du framework Symfony. Voici un résumé de ces failles critiques, leurs impacts potentiels, ainsi que les solutions mises en place par Symfony. De quoi comprendre les implications de ces vulnérabilités pour sécuriser vos applications.
Sommaire
Introduction
Même les frameworks les plus réputés comme Symfony ne sont jamais à l’abri de failles de sécurité. Quelle que soit la solution applicative retenue, la vigilance est de mise. Des sécurités comme un pare-feu applicatif ModSecurity ainsi que le blocage automatique des attaquants (fail2ban), combiné à une bonne politique de sauvegarde externalisée, sont indispensables.
Sur les hébergements web sécurisés LRob, nos serveurs Linux aident à votre sécurité applicative grâce à ModSecurity combiné à fail2ban qui bloquent activement les tentatives d’exploitation des failles; des sauvegardes externalisées complètes sont faites chaque jour avec une rétention d’un an. Choisir LRob comme hébergeur, c’est profiter d’une solution d’hébergement simple et sécurisée tout en ajoutant un sysadmin rigoureux, disponible et passionné à votre équipe !
Failles de sécurité Symfony (novembre 2024)
CVE-2024-51736 : Détournement d’exécution de commande sur Windows avec la classe Process
Versions concernées
Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.
Description
Cette faille permet un détournement d’exécution sur les systèmes Windows lorsque le fichier exécutable cmd.exe se trouve dans le répertoire de travail actuel. La classe Process pourrait alors exécuter ce fichier, ouvrant la voie à des détournements malveillants.
Résolution
Symfony a corrigé ce problème en forçant la classe Process à utiliser le chemin absolu vers cmd.exe.
Voir l’article officiel de Symfony.
CVE-2024-50341 : La méthode Security::login ignore le user_checker personnalisé
Versions concernées
Symfony versions >=6.2, <6.4.10; >=7.0, <7.0.10; >=7.1, <7.1.3.
Description
La méthode Security::login de Symfony ne prenait pas en compte le user_checker personnalisé, ce qui pouvait permettre des connexions non désirées.
Résolution
Le correctif implémente désormais un appel au user_checker configuré.
Voir l’article officiel de Symfony.
CVE-2024-50340 : Changement d’environnement via une requête
Versions concernées
Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.
Description
En manipulant une chaîne de requête spécifique, des utilisateurs peuvent changer l’environnement ou le mode de débogage du noyau lorsqu’une directive PHP register_argc_argv est activée.
Résolution
Le composant SymfonyRuntime ignore désormais les valeurs d’argv pour les environnements non CLI.
Voir l’article officiel de Symfony.
CVE-2024-50342 : Énumération d’adresses et de ports internes via NoPrivateNetworkHttpClient
Versions concernées
Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.
Description
Avec NoPrivateNetworkHttpClient, certaines informations internes pouvaient encore être exposées, permettant ainsi une énumération d’adresses IP et de ports.
Résolution
Le client NoPrivateNetworkHttpClient applique désormais un filtrage des IP bloquées dès le début de la résolution des hôtes.
Voir l’article officiel de Symfony.
CVE-2024-50343 : Réponse incorrecte du Validator avec une entrée se terminant par \n
Versions concernées
Symfony versions <5.4.43; >=6, <6.4.11; >=7, <7.1.4.
Description
Une validation utilisant une expression régulière pouvait être contournée en introduisant un caractère \n en fin d’entrée, ce qui entraînait une réponse incorrecte de la part du Validator.
Résolution
Symfony utilise désormais le modificateur regex D pour garantir une validation de toute l’entrée.
Voir l’article officiel de Symfony.
CVE-2024-50345 : Redirection ouverte via des URLs « sanitisées » par le navigateur
Versions concernées
Symfony versions <5.4.46; >=6, <6.4.14; >=7, <7.1.7.
Description
En exploitant des caractères spéciaux dans une URL, un attaquant pouvait détourner une redirection basée sur la classe Request pour envoyer les utilisateurs vers un autre domaine.
Résolution
La méthode Request::create vérifie désormais que les URI ne contiennent pas de caractères invalides.
Voir l’article officiel de Symfony.
Twig CVE-2024-51754 : Appels non protégés à __toString() dans un sandbox
Versions concernées
Twig versions <3.11.2; >=3.12, <3.14.1.
Description
Dans un environnement sandbox, un attaquant pouvait appeler la méthode __toString() d’un objet, même si cette méthode n’était pas autorisée par la politique de sécurité, ouvrant la porte à un contournement des restrictions du sandbox.
Résolution
Le mode sandbox vérifie désormais systématiquement l’appel à __toString() sur tous les objets.
Voir l’article officiel de Symfony.
Twig CVE-2024-51755 : Appels non protégés à __isset() et aux accès d’objets de type Array dans un sandbox
Versions concernées
Twig versions <3.11.2; >=3.12, <3.14.1.
Description
Dans un environnement sandbox, des objets ressemblant à des tableaux pouvaient exposer des attributs sans contrôle de sécurité. Cela permettait à un attaquant d’accéder à des propriétés potentiellement sensibles.
Résolution
Le mode sandbox contrôle désormais les propriétés des objets de type Array et l’appel à __isset() après vérification de sécurité.
Voir l’article officiel de Symfony.
Conclusion et recommandations de LRob
Ces huit failles montrent que même les frameworks les plus robustes comme Symfony ne sont pas à l’abri de vulnérabilités de sécurité. Heureusement, l’équipe Symfony a réagi rapidement pour fournir des correctifs. Et comme il se doit, les failles n’ont été rendues publiques qu’après leur correctif. Si vous utilisez Symfony, assurez-vous de mettre à jour dès que possible pour protéger vos applications et vos utilisateurs.
N’oubliez jamais qu’aucune solution logicielle n’est exempte de failles de sécurité. Votre vigilance doit être continue et les mise à jour régulières restent la meilleure ligne de défense face aux failles de sécurité et aux cybermenaces.
Chez LRob, nos serveurs offrent une sécurité optimale :
- Pas de faille Windows : Nos serveurs étant sous Linux, ils ne sont pas affectés par les failles spécifiques à Windows.
- Mise à jour applicatif serveur : Les logiciels serveur sont mis à jour quotidiennement et monitorés en 24/7.
- Pare-feu ModSecurity : En filtrant activement les requêtes malveillantes, notre pare-feu protège vos applications.
- Sauvegardes externalisées : Nous disposons de sauvegardes externalisées quotidiennes pour faciliter la récupération de données en cas d’incident, et vous pouvez aussi réaliser vos propres sauvegardes vers le FTP de votre choix (par exemple via un VPS Storage Cloud de PulseHeberg) via Plesk.
Laisser un commentaire