Trou de sécurité PHP : mises à jour disponibles

Posté par Netsabes le 27 février 2002 à 16:00. Modéré par oliv.

Étiquettes :

fév.

2002

Des trous de sécurité au niveau de l'upload de fichiers viennent d'être découverts dans toutes les versions de PHP depuis la 3.0.10.
Le PHP Group a réagi en sortant des mises à jour, dont l'installation est bien évidemment plus que recommandée, certaines des failles étant très simples à utiliser, selon le bulletin d'alerte.
Une version 4.1.2 est donc disponible en téléchargement, ainsi qu'une série de patches pour PHP 3, PHP 4.0.6 et PHP 4.1.x.

Les versions estampillées 4.2.0-cvs ne sont par contre pas soumises à ces failles, l'upload de fichiers ayant été réécrit dans cette version.

Aller plus loin

La page de téléchargement des patchs (3 clics)
La description des trous de sécurité (3 clics)
php (2 clics)

# Avez vous patché ...

Posté par Obi MO (site web personnel) le 27 février 2002 à 16:07. Évalué à 3.

Da Linux French Page ?
C'était juste une connerie // -1
- [^] # Re: Avez vous patché ...
  
  Posté par Gaël Le Mignot le 27 février 2002 à 20:29. Évalué à 5.
  
  Si tu lisais la news: " Des trous de sécurité au niveau de l'upload de fichiers", daCode n'utilise jamais la fonction d'upload de fichiers de PHP, il n'y a donc aucun risque...
  
  t'as mis en -1 donc moi aussi ;)
  - [^] # Re: Avez vous patché ...
    
    Posté par Netsabes le 27 février 2002 à 21:14. Évalué à 10.
    
    daCode n'utilise jamais la fonction d'upload de fichiers de PHP, il n'y a donc aucun risque...
    
    A vue de nez, sur au moins deux scripts, tous deux ne nécessitant pas d'être admin.
# Risk: Critical : aie !

Posté par Timbert Benoît le 27 février 2002 à 16:13. Évalué à 10.

Des bug pareils ça fait mal...
(apparament ça varie un peu suivant les versions)

On est pas à l'abris d'un truc genre Code Red pour Php, c'est pour ça qu'il faut patcher !

(note que dans certaines conf sécurisées, on n'est pas vulnérable)
- [^] # Re: Risk: Critical : aie !
  
  Posté par kael le 27 février 2002 à 20:52. Évalué à 5.
  
  nan il faut patcher parce que c'est le boulot de tout administrateur de tenir sa/ses machine(s) le plus 'secure' possible.
  L'existence de trucs comme code-red n'est qu'une consequence de la negligence des admins (ou le manque de reactivité du responsable du programme incriminé)
  
  (j'englobe dans le terme admin toute personnes responsable d'une machine connecte sur internet, particulier ou pro. )
# Question

Posté par kadreg le 27 février 2002 à 16:28. Évalué à 10.

Ce trou est-il dans l'upload de fichier ou dans l'upload de fichier ?

Bon d'accord, c'est con. Je repose la question autrement. Pour exploiter ce trou, il faut attaquer une page qui fait de l'upload de fichier ( un truc comme ça : http://kadreg.free.fr/perso/(...) ), c'est un trou qui peut potentiellement exister dans toutes les pages si on les appelle par un POST avec un fichier accroché ?
- [^] # Re: Question
  
  Posté par Netsabes le 27 février 2002 à 16:38. Évalué à 5.
  
  Dans la mesure où les trous de sécurité ne sont pas détaillés, c'est pas aisé à dire. Mais je pense que c'est le genre de trous qui fonctionnent partout (enfin, c'était une fonctionnalité, quoi).
  
  Faudrait se taper le code du patch pour voir précisément, en fait.
  - [^] # Reponse
    
    Posté par kadreg le 27 février 2002 à 16:45. Évalué à 10.
    
    We found several flaws in the way PHP handles multipart/form-data POST requests.
    
    C'est donc la fonction qui traite le multipart/form-data en entrée qui a le trou. Pour que cette fonction s'active, il suffit d'un appel de la page par POST avec un fichier accroché. Ca n'a rien a voir avec le traitement de la page PHP qui agit une fois le fichier arrivé.
    
    Donc, si j'ai bien compris, tous les serveurs web avec PHP y sont sensibles.
    
    Bon, ce soir, c'est soirée update.
    - [^] # Re: Reponse
      
      Posté par Gradix le 27 février 2002 à 19:29. Évalué à 4.
      
      il y a plus d'explications et une démo pratique ici :
      http://www.securiteam.com/unixfocus/5PP01152KE.html(...)
      - [^] # Re: Reponse
        
        Posté par Anonyme le 28 février 2002 à 00:14. Évalué à 5.
        
        T'as vu la date ? 4/9/2000... c'est un _vieux_ bug... pas celui qui nous intéresse...
        
        [^] # Re: Reponse
        
        Posté par Éric (site web personnel) le 28 février 2002 à 11:26. Évalué à -1.
        
        Non, ca n'est meme pas une faille de PHP mais une faille du programmeur, qui ne vérifie pas ce que contiennent ses variables. Enfin elle est vieille celle là, mais toujours d'actualité, les newbie se servant d'ancien tutorials qui disent d'utiliser les mauvaises méthodes.
        
        (-1, HS)
    - [^] # Re: Reponse
      
      Posté par dido le 27 février 2002 à 19:32. Évalué à 1.
      
      Unfourtunately there are several flaws in the php_mime_split function that could be used by an attacker to execute arbitrary code.
      
      Donc, si j'ai bien compris, tous les serveurs web avec PHP y sont sensibles.
      
      Mon anglais laisse peut-être à désirer, mais j'ai plutôt compris que c'est la fonction php_mime_split qui pose problème, et donc seul les sites l'utilisant sont concernés.
      - [^] # Re: Reponse
        
        Posté par Netsabes le 27 février 2002 à 19:37. Évalué à 3.
        
        php_mime_split est une fonction de PHP (du C, quoi), pas une fonction PHP utilisable dans un site.
        Et je suppose que php_mime_split est appelé automatiquement quand y'a upload de fichiers, ce qui expliquerait le trou.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 27 février 2002 à 20:16. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Reponse
        
        Posté par Netsabes le 27 février 2002 à 20:59. Évalué à 3.
        
        La version CVS, oui.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 27 février 2002 à 21:24. Évalué à 0.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Reponse
        
        Posté par Netsabes le 27 février 2002 à 22:45. Évalué à 0.
        
        Ca a été fait fin janvier, donc effectivement, ça passera pas chez toi.
        Je compte mettre à jour toute cette partie-là ce week-end, histoire de rendre le tout compatible 4.n.0 (n correspondant à la version de PHP où track-vars passera à Off par défaut. Actuellement, n vaut 2).
        
        [^] # Re: Reponse
        
        Posté par Éric (site web personnel) le 28 février 2002 à 11:28. Évalué à 1.
        
        track-vars ? off ?
        
        euh ......
        
        register_global(s?) à off tu veux dire je pense.
        
        D'ailleurs impossible d'enlever le track-vars sur les dernieres versions (depuis 4.0.3) si je ne me trompe pas. (heureusement)
        
        [^] # Re: Reponse
        
        Posté par Netsabes le 28 février 2002 à 17:42. Évalué à 1.
        
        Non non, register globals off, c'est réglé (cf posts précédents).
        
        Pour le track-vars, ils pensent (enfin, un coup ils pensent, un coup ils trouvent que c'est une mauvaise idée) le mettre par défaut à Off dans une version future (aux dernières nouvelles, la 4.2.0, donc).
        C'est d'ailleurs tout à fait modifiable à la compil', c'est juste mis par défaut à On actuellement (oui, depuis la 4.0.3).
        Le but avoué est de forcer les gens à utiliser les nouveaux tablaux $_*[], en remplacement des $HTTP_*_VARS (qui existeront plus si track-vars est mis à Off).
        
        [^] # Re: Reponse
        
        Posté par DPhil (site web personnel) le 28 février 2002 à 01:16. Évalué à 0.
        
        C'est pas le bon bug que tu décris, il est corrigé en ajoutant la fonction is_uploaded_file ( string filename) qui vérifie que le fichier n'est pas un fichier local (ça date de plus d'un an)
# PHP

Posté par ours Ours (site web personnel) le 27 février 2002 à 16:36. Évalué à -3.

C'est dommage que PHP soit uniquement abouti un projet abouti au niveau fonctionnalité, mais qu'il ne le soit pas niveau sécurité.

(Ce n'est pas spécifiquement le problème de PHP, IIS/ASP sortent des patchs très souvent)

Bah beaucoup de problèmes devraient se résoudre quand Apache 2.0 sera finalisé. On pourra beaucoup plus facilement se passer du safe mode :)
- [^] # Re: PHP
  
  Posté par gle le 27 février 2002 à 18:56. Évalué à -2.
  
  C'est marrant, j'ai pas souvenir que PSP ait eut ce genre de trous.
- [^] # Re: PHP
  
  Posté par Anonyme le 27 février 2002 à 20:03. Évalué à -2.
  
  « C'est dommage que PHP soit uniquement abouti un projet abouti au niveau fonctionnalité, mais qu'il ne le soit pas niveau sécurité. »
  
  On trouvera toujours des failles dans tout les logiciels. Je ne vois pas ce qui te permet de dire que la sécurité dans PHP n'est pas aboutie.
  
  Quand à IIS/ASP, il ne me semble pas que les patchs soient disponibles si souvent.
  - [^] # Re: PHP
    
    Posté par ours Ours (site web personnel) le 27 février 2002 à 20:45. Évalué à 0.
    
    arf pour IIS, y a toujours des petits patchs à 10 balles, bref un boulot monstre pour l'admin réseau. Faut tout surveiller.
    
    Je voulais juste dire que - si tu regardes les MAJ de PHP - très souvent, une MAJ vient corriger des bugs qqes jours après la sortie. Prends pour exemple le passage de la 4.1.0 et la 4.1.1
    
    Bref ce qui est critiquable, c'est que dans certains cas, le passage en release candidate ne dure pas assez longtemps.
    - [^] # Re: PHP
      
      Posté par ours Ours (site web personnel) le 01 mars 2002 à 09:00. Évalué à 1.
      
      juste une précision, je n'ai jamais dit que IIS/ASP était > à PHP, loin de là
# Euh... Les paquetages ad hoc ?

Posté par William Steve Applegate (site web personnel) le 27 février 2002 à 18:02. Évalué à 4.

Bon, puisqu'il y a des gars de chez Mdk qui moulent sur^W^Wlisent LinuxFR (Amaury, t'es dans le coin ?), je pose ma question : quand les RPM pour la Mdk devraient-ils arriver ? J'ai pas du tout envie de m'amuser à tout recompiler (10 machines à mettre à jour, les problèmes de dépendances qui s'ensuivraient... non merci !) et j'aimerais pas non plus voir un 3l33t crétin me foutre le souk. Du coup, j'aimerais savoir s'il y a bien quelqu'un chez Mandrakesoft en train de packager ce truc et quand cela va arriver... ça me soulagerait l'esprit :-)
Envoyé depuis mon PDP 11/70
- [^] # Euh... Les paquetages ad hoc ?
  
  Posté par matiasf le 27 février 2002 à 18:25. Évalué à 10.
  
  Tu devrais poser la question a mdk ? non
  
  Afin, si tu te documentes un peu sur rpm, il est assez facile a partir du paquage .src.rpm d'ajouter le patch et faire de nouveaux .i386.rpm. Si t'as change de numero de release pour le paquage, un rpm -U doit marcher. Attention, /etc/php.ini d'origine est peut-etre renome php.ini.rpmsave.
  - [^] # Re: Euh... Les paquetages ad hoc ?
    
    Posté par Anonyme le 27 février 2002 à 20:29. Évalué à 3.
    
    Pour le « paquage » ? Quelle horreur !!!
    
    PAQUET : c'est du français, ça désigne cela, et c'est court !
    
    Concernant les rpm, il suffit de faire un rpm -ivh *.src.rpm, d'appliquer le patch dans /usr/src/redhat/sources (enfin là se trouve les sources), de faire un configure (qui génère un .spec) et de faire un rpm --ba php.spec
    - [^] # Re: Euh... Les paquetages ad hoc ?
      
      Posté par matiasf le 27 février 2002 à 20:55. Évalué à 3.
      
      > PAQUET : c'est du français, ça désigne cela, et c'est court !
      
      Juste.
      
      > Concernant les rpm, il suffit de faire un rpm -ivh *.src.rpm...
      
      Si ta procédure marche, il faut nous le dire !
      Car pour ma part je serai, tres, tres surpris que ca marche et j'ai peur que tu envois des gens dans une impasse.
      
      1- meme si le patch est appliqué dans /usr/src/redhat/SOURCES/php-4.0.6/ il ne sera pas utilisé car le paquet est construit depuis /usr/src/redhat/BUILD/php-4.0.6/ qui est un désarchivage de /usr/src/redhat/SOURCES/php-4.0.6.tar.gz (l'une des premières chose realisé par "rpm -ba /usr/src/redhat/SPECS/php.spec").
      
      2- le .spec généré apres un ./configure ignora le patch. c'est-à-dire qu'il n'y aura pas de ligne :
      
      Patch3: php-4.0.6-upload.patch
      [...]
      %patch3 -p1 -b .upload
      
      dans le fichier .spec par exemple.
      A moins que le patch patche aussi le systeme qui contruit de le fichier .spec (tres peu probable). Et le fichier .spec généré est en general un fichier minium qui ne tient pas compte des specificité des distrib. Un diff devrait te convaincre.
      
      Ceci dit, ta procedure peut marcher si tu recrés /usr/src/redhat/SOURCES/php-4.0.6.tar.gz avec le patch. Mais dans ce cas, tu ne "respectes" pas rpm qui assure la "traçabilité" (archive d'origine puis les patchs appliqués et non une archive patché de partout).
      
      Que ceux qui ne "maitrise" par rpm/apt ne panique pas, il suffit d'attendre les mises à jour par les distributeurs. Et sous Linux c'est beaucoup plus rapide que chez MS. Par exemple...
# $sarass PHP

Posté par swix le 28 février 2002 à 02:06. Évalué à 4.

Super... Après avoir passé un server de 4.0.5 à 4.1.2 je m'aperçois que la fonction crypt() ne fonctionne plus de le meme facon: bravo pour la cohérence :-(.

Dans le 4.0.5 crypt("abc") renvoyait une chaine de 13 chars DES, et la ca renvoie une sorte de hash MD5: tres pratique: ca casse pas mal de scripts basés sur crypt(), donc quelques vieux phpnuke et autres.... Si au moins c'etait documenté dans les release notes...

Moralité, retour à un php 4.0.6 patché...
- [^] # Re: $sarass PHP
  
  Posté par Benoît Sibaud (site web personnel) le 28 février 2002 à 11:16. Évalué à 2.
  
  Il doit utiliser PAM, qui sur ta machine doit fournir du MD5. Donc tu recompiles en virant le support PAM (je ne sais pas s'il peut se virer simplement par configuration).
- [^] # Re: $sarass PHP
  
  Posté par Éric (site web personnel) le 28 février 2002 à 11:38. Évalué à 2.
  
  Crypt() utilise la méthode par défaut de ton système. Sauf si je me trompe c'était déjà son fonctionnement avant.
  
  Tu n'aurais pas mis d'autres trucs à jour en même temps qui auraient pu changer ca ?
  - [^] # Re: $sarass PHP
    
    Posté par swix le 28 février 2002 à 12:19. Évalué à 1.
    
    non justement, rien que le php... merci quand meme pour l'info :)
- [^] # Re: $sarass PHP
  
  Posté par swix le 28 février 2002 à 13:36. Évalué à 1.
  
  bon,j'ai trouvé un workaround!
  
  en fouillant sur google, j'ai vu ce mail de rasmus:
  http://groups.google.com/groups?hl=fr&ie=utf-8&oe=utf-8&(...)
  
  d'ou la solution:
  0. make distclean
  1. ./configure [options]
  2. éditer main/php_config.h et indiquer PHP_MD5_CRYPT = 0
  3. compiler et installer :-)
  
  Morale de l'histoire: open Source & google rulez :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.