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
- PHP (1 clic)
- Description de la faille (1 clic)
- Page de téléchargement (0 clic)
# Re: Trou de sécurité dans PHP 4.3.0
Posté par fleny68 . Évalué à -4.
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 bastien Sé . Évalué à 10.
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 Raphaël SurcouF . Évalué à 5.
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 Xavier Antoviaque (site web personnel) . Évalué à 3.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Moby-Dik . Évalué à -1.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Moby-Dik . Évalué à 3.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Xavier Antoviaque (site web personnel) . Évalué à 10.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par matiasf . Évalué à 6.
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 Xavier Antoviaque (site web personnel) . Évalué à 10.
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 matiasf . Évalué à 4.
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 matiasf . Évalué à 5.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par ours Ours (site web personnel) . Évalué à 4.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Christophe BAEGERT . Évalué à 7.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par matiasf . Évalué à 7.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Christophe BAEGERT . Évalué à 2.
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Xavier Antoviaque (site web personnel) . Évalué à 7.
L'intuitivité de ce type de solutions n'étant pas encore forcément au rendez-vous, il est toujours cependant recommandé de posséder de bonnes connaissances dans ce domaine. Mais ça vient. :-)
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Ben A. . Évalué à 8.
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 Moby-Dik . Évalué à -2.
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 matiasf . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.