Ce plugin dispose d’une base d’installations dépassant le million et est donc une cible potentielle d’attaques. Il fournit environ 80 éléments et extensions pour aider à la conception et la personnalisation des pages web.
La vulnérabilité, si elle était exploitée, permettrait l’exécution d’un code arbitraire. Patchstack, société à l’origine de la découverte, explique :
« Cette faille permet à n’importe quel utilisateur, quel que soit leur statut d’authentification et d’autorisation, de réaliser une attaque par inclusion de fichier local. Cette attaque peut être utilisée pour inclure des fichiers locaux dans le système de fichier du site web, comme dans /etc/passwd. ». Elle ajoute que l’on peut exploiter une autre faille par l’inclusion d’un code PHP qui sera exécuté dans les mêmes conditions.
Il y a un facteur limitant : il faut que des widgets comme la galerie dynamique ou de produits soient utilisés. La faille est cependant considérée comme critique et les personnes concernées sont invitées à migrer vers la version 5.0.5 du plugin aussi vite que possible. Toutes les versions antérieures sont vulnérables.
Commentaires (12)
#1
J’ai un peu de mal à comprendre certains points.
“quel que soit leur statut d’authentification et d’autorisation”
Une personne non authentifiée est inclus dans cette liste ?
“comme dans /etc/passwd.”
Apache a les droits d’écriture sur ce fichier de base ? Ce n’est pas nécessaire dans le cadre de cette faille ?
#1.1
Par défaut Apache (ou PHP) n’a accès qu’en lecture à ce fichier.
Sur un hébergement bien fait, PHP tourne a part en mode FPM. Chaque process PHP-FPM est exécuté avec un user relatif au site web et il ne peut pas sortir de son dossier.
Maintenant, ce n’est pas la cas partout…
#1.2
Heuresement ça doit rester rare tout de même d’avoir des cas ou /etc/passwd est modifiable par le process php, peut être des containers docker mal foutus ou des système dépanné à grand coups de chmod 777….
Ceci dit l’exemple est mal choisis, le simple fait de pouvoir déposer des fichiers et de les faire exécuter par le user de php est déjà suffisamment critiques pour ne pas avoir besoin de ce type d’exemple.
#1.3
Tout à fait. Aucune distri ne met les droits écriture a tout le monde par défaut.
Critique pour le site oui… Mais pas tant que ça pour le serveur. Ce qui change tout dans le cadre des hébergements mutualisés.
Quand tu as tout bien fait et que ton site ce fait pourrir par un autre site qui est sur le même serveur, ya de quoi râler.
#1.4
FPM ?
Tu veux dire créer un user unique pour le site avec l’autorisation pour seulement les fichiers nécessaires ?
De vrais site sont en ligne aujourd’hui sans cela ?!
#2
De ce que je comprend, n’importe qui peut inclure (au sens PHP, donc interprété en PHP) “dans la page web” n’importe quel fichier du système de fichiers du serveur.
#3
Original:
La vulnérabilité LFI permet à un attaquant d’inclure le contenu d’un fichier local (= du serveur) dans la page web en cours. Suivant la manière de l’inclure, il sera soit affiché, soit interprété par le serveur web.
#4
Vous seriez surpris… Sur le forum de prestashop, j’avais demandé fin 2020 ce que pensaient les gens du fait que la version qui sortait serait enfin compatible avec PHP7.3… moins d’un mois avant l’expiration de la maintenance de celui-ci.
Je me suis vu répondre par des “super” utilisateurs du forum que ça n’avait pas d’importance, un se vantant même d’avoir des sites qui tournaient encore en PHP4…
#4.1
Wouah c’est chaud !
Suffit presque d’aller chercher les CVE qui correspondent pour commencer à mettre le bordel. (avec des connaissances bien entendu).
#5
En complément, de ce que je dis au dessus sur Prestashop, le jour où Internet sera audsi débarrassé des sites WordPress vendus par des webagencies qui savent juste faire des thèmes et installer des plugins sans avoir la moindre idée de ce qu’ils font, des fois pour des sites vitrines de 5-6 pages, ben le Web sera plus sûr.
J’ai même vu des gens faisant des sites vitrines avec Symfony, probablement parce que c’est ce qu’ils avaient appris à l’école.
Ou comment utiliser le même outil pour tout ses travaux…
#6
Oui, pas mal de serveur fonctionne avec mod_php Apache :(
#6.1
J’vais check ce dont tu parles, je suis pas autant calé