Trou de sécurité dans PHP 4.3.0

Posté par . Modéré par Xavier Antoviaque.
Tags :
0
17
fév.
2003
PHP
Le PHP Group vient d'annoncer qu'un trou de sécurité avait été découvert dans la version CGI de PHP 4.3.0, la toute dernière version en date du célèbre langage de script, très utilisé sur le web.

PHP 4.3.1, corrigeant ce trou de sécurité, vient de sortir dans la foulée. Tous ceux qui utilisent la version CGI de PHP 4.3.0 sont évidemment fortement invités à mettre à jour leur version de PHP.

NdM : Merci à Christophe Guilloux d'avoir également proposé cette dépêche. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


PHP Security Advisory: CGI vulnerability in PHP version 4.3.0

Issued on: February 17, 2003
Software: PHP/CGI version 4.3.0
Platforms: All


The PHP Group has learned of a serious security vulnerability in
the CGI SAPI of PHP version 4.3.0.


Description

PHP contains code for preventing direct access to the CGI binary with
configure option "--enable-force-cgi-redirect" and php.ini option
"cgi.force_redirect". In PHP 4.3.0 there is a bug which renders these
options useless.

NOTE: This bug does NOT affect any of the other SAPI modules.
(such as the Apache or ISAPI modules, etc.)


Impact

Anyone with access to websites hosted on a web server which employs
the CGI module may exploit this vulnerability to gain access to any file
readable by the user under which the webserver runs.

A remote attacker could also trick PHP into executing arbitrary PHP code
if attacker is able to inject the code into files accessible by the CGI.
This could be for example the web server access-logs.


Solution

The PHP Group has released a new PHP version, 4.3.1, which incorporates
a fix for the vulnerability. All users of affected PHP versions are
encouraged to upgrade to this latest version. The downloads web site at

http://www.php.net/downloads.php

has the new 4.3.1 source tarballs, Windows binaries and source patch
from 4.3.0 available for download. You will only need to upgrade if
you're using the CGI module of PHP 4.3.0. There are no other bugfixes
contained in this release.


Workaround

None.


Credits

The PHP Group would like to thank Kosmas Skiadopoulos for discovering
this vulnerability.


Copyright (c) 2003 The PHP Group.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+USOr/HlsOzK2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV
tUERfwp/RXtcH13vdv0CGGY=
=rYm5
-----END PGP SIGNATURE-----

Aller plus loin

  • # Re: Trou de sécurité dans PHP 4.3.0

    Posté par . Évalué à -4.

    Je n'ai pas très près bien compris. Celui qui a dévouvert ce trou n'a prévenu que les gens de chez PHP, et le trou n'est annoncé qu'en même temps que le correctif est fournit?

    Est-ce qu'il n'aurait pas été plus sage d'annoncer les trous tout de suite, pour que les victimes potentielles puisse désactiver le module CGI ?

    Des ptits trous des ptits trous encore des ptits trous. Des trous d'première classe...
    • [^] # Re: Trou de sécurité dans PHP 4.3.0

      Posté par . Évalué à 10.

      Oui bien sur, d'annoncer la faille en public sans proposer de solution pour que tous les serveurs se fassent descendre par des script kiddies... Bonne idée!

      En général on attends une semaine avant de le publier, si y a un seul mec qui l'a trouvé depuis que c'est sorti y a peu de chance qu'un autre mec le trouve le temps de faire le patch!
      • [^] # Re: Trou de sécurité dans PHP 4.3.0

        Posté par . Évalué à 5.

        Parce que tu mets à jour tes serveurs en production dés qu'une version majeure pointe le bout de son nez ?
        Sachant que php a déjà eu d'importants changements au niveau syntaxique,
        pour ne citer que celui-là, j'estime que c'est jouer avec le feu...
        Normalement, le temps que tu testes php 4.3.0 sur un serveur de test,
        tu n'as pas eu celui d'etre pris à parti par la découverte du trou de sécurité.
        Enfin, si tu utilises, par exemple, une debian, php 4.3.0 ne sort pas de la sid tant que le trou existe... (Ah ? tu utilisais la version unstable en prod ?...)
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par (page perso) . Évalué à 3.

          La 4.3.0 n'a pas apporté de changement au niveau de la syntaxe; c'est principalement un (gros) correctif de bugs.
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par (page perso) . Évalué à 2.

          sauf que si je ne me trompe pas la 4.3 amenait elle meme une correction coté sécurité.
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par . Évalué à -1.

          Une version numérotée 4.3.1, c'est une version majeure ? Faut pas oublier de dormir le soir...
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par . Évalué à 3.

          NB : la version 4.3.0 a été installée chez de nombreux hébergeurs (OVH par exemple, je crois). Une des nouveautés intéressantes est l'intégration d'une version adaptée de la libgd, ce qui diminue les problèmes d'installation de librairies externes (les différentes versions de GD, c'est un peu le bordel...). Cette version de GD inclut les "dernières" nouveautés intéressantes comme le changement de taille intelligent (i.e. avec rééchantillonnage pour éviter la pixellisation) : génial pour toutes les applis de gestion de galeries (création automatique de thumbnails).
    • [^] # Re: Trou de sécurité dans PHP 4.3.0

      Posté par (page perso) . Évalué à 10.

      Le module CGI n'est pas qu'un "module", c'est un mode d'utilisation du PHP. Si un hébergeur l'utilise, il ne peut pas passer à un autre mode (module apache par exemple) sans bouleverser son architecture système.
    • [^] # Re: Trou de sécurité dans PHP 4.3.0

      Posté par . Évalué à 6.

      > désactiver le module CGI ?
      php en cgi, c'est pas php en module. php en module s'exécute avec apache (même pid). pour php en cgi, apache fait un exec("/usr/bin/php"). Généralement, php en cgi est utilisé via su_exec ou équivalent pour changer de compte. apache tourne sous le compte "web" par exemple. Mais si, par exemple, tu demandes http://website.org/~toto/(...) ou http://toto.website.org/,(...) php en cgi va être lancé sous le compte toto. Çà renforce significativement la sécurité surtout lorsque plusieurs sites sont hébergés par un même serveur. Dans ce cas, passé en module php, est un plus gros risque que de continuer à utiliser php v4.3.0 en cgi.
      • [^] # Re: Trou de sécurité dans PHP 4.3.0

        Posté par (page perso) . Évalué à 10.

        Oula, attention aux confusions. Le suexec n'est pas automatique, et pas forcément selon les règles d'URL que tu indiques; c'est à l'administrateur de savoir le régler.

        Quant à savoir si le module apache est plus sûr que l'utilisation du CGI, c'est une querelle de clocher, mais c'est une question qui de toutes façons ne se prend pas à la légère dans le cadre d'un hébergement cloisonné. Etant donné que les bugs de ce genre dans PHP ne sont pas rares, j'aurais plutôt tendance à préférer du CGI en comptes séparés via suexec ou équivalent.

        C'est en tous cas la solution retenue sur Plebia; elle expose à moins de dangers en cas de défaillance de PHP (l'exposition des sources d'un compte web dans un cas, de tous dans l'autre).
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par . Évalué à 4.

          > c'est à l'administrateur de savoir le régler.

          C'est claire. Et la mise au point d'une bonne config n'est pas évidente et demande de bonnes connaissances des possibilités de configuration d'apache ET php.

          > Quant à savoir si le module apache est plus sûr que l'utilisation du CGI, c'est une querelle de clocher

          Çà dépend des besoins. Mais php en cgi (avec apache et suexec ou cgi_wrap etc...et une bonne configuration :o] ) offre plus de possibilités que php en module. Quoiqu'il en soit, si php en module est suffisant (cas d'une machine dédié à un site), c'est pas la peine de se faire "chié" avec php en cgi.
  • # Re: Trou de sécurité dans PHP 4.3.0

    Posté par . Évalué à 5.

    C'est assez grave mais.... il faut relativiser. A ma connaissance, il n'y a pas de distribe avec cette version de php. Enfin, --enable-force-cgi-redirect, renforce la sécurité. çà impose l'utilisation d'une redirection pour utiliser php en cgi (on ne peut utilisé php n'importe où, il faut utilise scripalias, addhandler, action, etc...). C'est-à-dire qu'un serveur apache bien configuré, même sans --enable-force-cgi-redirect n'a pas de problème de sécurité. On a le même niveau ne sécurité que n'importe quel cgi. Pas moins.
    • [^] # Re: Trou de sécurité dans PHP 4.3.0

      Posté par (page perso) . Évalué à 4.

      La plupart du temps les hébergeurs recompilent apache / php parce qu'ils ne correspondent pas totalement à leurs besoins
      • [^] # Re: Trou de sécurité dans PHP 4.3.0

        Posté par . Évalué à 7.

        Oui, et ces hébergeurs là connaissent les problèmes de sécurité, c'est pas un problème pour eux.
      • [^] # Re: Trou de sécurité dans PHP 4.3.0

        Posté par . Évalué à 7.

        Il y a quelque année, il était courant de recompilé apache et php. Maintenant, la recompilation est plus rarement justifiée. D'ailleur je ne le fait plus depuis quelque mois car apache et php sont livrés, dans les distribe, avec une bonne "tripotée" de modules et d'excellentes possibilités de configuration sans recompiler. Çà rend aussi la maintenance moins "chiante". Inutil de recompiler, on installe les errata. C'est le progrès. C'est comme pour le noyau. Avec les modules, les recompilations se font plus rare.
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par . Évalué à 2.

          Pour héberger son propre site effectivement ce n'est pas très utile. Mais pour faire du mutualisé massif, il sera toujours indispensable de recompiler.
        • [^] # Re: Trou de sécurité dans PHP 4.3.0

          Posté par . Évalué à 8.

          La recompilation se justifie encore aujourd'hui notamment pour retirer les trucs inutiles (voire dangereux) car, meme avec un systeme de modules a la mod_so, beaucoup de modules sont activés dans le "core".

          De plus, certaines options sont encore definies au moment de la compilation et une configuration chez un hebergeur differe tres largement d'une machine personnelle.

          Et pour finir, il y a tout interet a essayer de reduire la taille memoire du kernel, des executables puisque, chez un hebergeur, il y a souvent plethore de machines quasi identiques et donc, tout gain sera repercute sur l'ensemble du parc.

          Cependant, je ne pense pas non plus que l'extreme du "je compile/personnalise tout" soit une bonne idee. Je dis qu'un hebergeur qui veut maitriser sa plateforme et essayer d'en tirer le maximum a tout interet a essayer de reduire le "gras" de certains services critiques et le temps perdu par la maintenance qui en decoule sera largement compensée par une connaissance et une maitrise accrues de ses outils (et l'efficacite qui en resultera).
          • [^] # un ptit flame

            Posté par . Évalué à -2.

            Je dis qu'un hebergeur qui veut maitriser sa plateforme et essayer d'en tirer le maximum a tout interet a essayer de reduire le "gras" de certains services critiques et le temps perdu par la maintenance qui en decoule sera largement compensée par une connaissance et une maitrise accrues de ses outils (et l'efficacite qui en resultera).

            Comme chez Proxad, société reconnue pour les performances de ses serveurs d'hébergement mutualisé PHP/MySQL (Online, Free).

            Dis, Tonton, pourquoi tu tousses ?
          • [^] # Re: Trou de sécurité dans PHP 4.3.0

            Posté par . Évalué à 2.

            > La recompilation se justifie encore aujourd'hui

            J'ai pas dis le contraire. J'ai uniquement dit que c'était plus rare et que c'est positif. Cet avis global, ça ne veut pas dire que dans certains cas, il n'est pas "positif" d'avoir la possibilité de recompiler.

Suivre le flux des commentaires

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