Vulnérabilité dans PHP 4.2.0 et 4.2.1

Posté par  . Modéré par Pascal Terjan.
Étiquettes : aucune
0
22
juil.
2002
PHP
Un intrus peut exécuter du code avec les privilèges du serveur web.

C'est dû à un défaut de l'analyse des entêtes de requêtes HTTP POST lorsque la requête envoie du "multipart/form-data". (formulaire, envoie de fichiers).

Bien sûr, aucun serveur web ne tourne sous l'utilisateur root, n'est-ce pas ?

Méthode temporaire pour bloquer le problème (seulement si vos programmes PHP n'utilisent pas le HTTP POST):
ajouter dans la config du serveur web:

Order deny,allow
Deny from all


Il semblerait que le site soit assez surchargé...

NdM : j'ai ajouté un lien vers un miroir allemand dans la mesure où les français ne sont pas à jour.
Update : http://fr.php.net est maintenant à jour

Aller plus loin

  • # Rhaaaaaaaah !

    Posté par  . Évalué à 10.

    Encore des boeufs qui ne téléchargent pas les patchs ! Comment peut-on surcharger un site en téléchargeant des patchs de 53Ko ?

    • [^] # Re: Rhaaaaaaaah !

      Posté par  . Évalué à 10.

      Surtout que le patch se resume a meme pas une centaine de lignes une fois que tu as enleve les 2 miyards de lignes pour mettre a jour "configure" (alors qu'il suffit de faire un ./buildconf apres le patch) Sinon, il est interessant de relever que l'architecture IA 32 n'est exploitable que sous la forme d'un DOS (et donc n'est pas a priori exploitable) : <<<< Impact Both local and remote users may exploit this vulnerability to compromise the web server and, under certain conditions, to gain privileged access. So far only the IA32 platform has been verified to be safe from the execution of arbitrary code. The vulnerability can still be used on IA32 to crash PHP and, in most cases, the web server. >>> Plus d'infos sur http://security.e-matters.de/advisories/022002.html

    • [^] # Re: Rhaaaaaaaah !

      Posté par  (site web personnel) . Évalué à 10.

      Problème : le patch n'est utile que si l'on n'a pas supprimé les sources ! Solution : prendre le patch et chercher la version précedente sur le premier miroir venu.

  • # Mise a jour des miroirs francais

    Posté par  (site web personnel) . Évalué à 10.

    Bonjour, J ai bien entendu relancé le rsync de http://fr.php.net dès l annonce du trou de sécurité. C est en train de se faire. Le seul problème, c est que, comme le souligne la news, le site principal est assez chargé en ce moment. Patience donc. Guillaume

  • # Puisqu'on parle de PHP...

    Posté par  (site web personnel) . Évalué à 10.

    Attention aussi : meme si Apache est lancé en tant que nobody, les futurs warlordz pourront lire vos fichier .php non éxécutés. Et que peut-on faire avec des .php non éxécutés ? A tout hasard, trouver le pass mysql ? et si par hasard c'était le meme que le shell de l'utilisateur concerné ? Bref, attention a bien upgrader ! Concernant le support de PHP dans Apache 2.0, puisque c'est dans le sujet, et bien : ca manque de testeurs (d'après ce que j'ai pu comprendre) ! Le code est assez stable, mais impossible de tout tester sans plus de testeurs et de bugs-report. De plus le support du safe-mode semble merder avec Apache 2.0, mais un patch cochon règle temporairement le problème. Pour ceux qui sont intéressés par ca : http://www.netlibre.info/~airmax/phpinfo.php -> prendre apache sur le CVS (sur le CVS, pas les snapshots qui marhcent pas) -> prendre la branche non-stable de PHP sur le CVS (ou le snapshot). -> prendre le patch : http://www.slamb.org/php-apache2-safemode.patch Voila, avec ca vous saurez vous debrouiller pour avoir la meme chose. Je vous raconte pas le temps que j'ai perdu pour réussir a faire marcher ca. Maxime, qui aurait mieux fait de rester a Apache 1.3...

  • # fr.php.net croule

    Posté par  (site web personnel) . Évalué à 5.

    utilisez be.php.net : y'a personne !!!

  • # oui je sais sai mal

    Posté par  (site web personnel) . Évalué à -10.

    de poster ca ici mais cela fait des mois que j'en chie, ni ma hotline (ovh), ni les ng fr.comp.lang.php ou fr.comp.infosystemes.www.serveurs n'ont pu me répondre: lors d'une seconde compilation de php4.2.1 (et cela me tombe encore sur php4.2.2) j'obtiens cette erreur en fin de compilation: 
    make[1]: Entre dans le répertoire `/home/ovh/src/php-4.2.2'
gcc -I. -I/home/ovh/src/php-4.2.2/ -I/home/ovh/src/php-4.2.2/main -I/home/ovh/src/php-4.2.2 -I/home/ovh/src/apache_1.3.26/src/include -I/home/ovh/src/apache_1.3.26/src/os/unix
-I/home/ovh/src/php-4.2.2/Zend -I/usr/include/freetype2/freetype -I/home/ovh/src/gd-2.0.1 -I/usr/include/imap -I/usr/local/mysql/include/mysql -I/usr/include/pgsql
-I/home/ovh/src/php-4.2.2/ext/xml/expat  -I/home/ovh/src/php-4.2.2/TSRM -g -O2  -c stub.c && touch stub.lo
/bin/sh /home/ovh/src/php-4.2.2/libtool --silent --mode=link gcc  -I. -I/home/ovh/src/php-4.2.2/ -I/home/ovh/src/php-4.2.2/main -I/home/ovh/src/php-4.2.2
-I/home/ovh/src/apache_1.3.26/src/include -I/home/ovh/src/apache_1.3.26/src/os/unix -I/home/ovh/src/php-4.2.2/Zend -I/usr/include/freetype2/freetype -I/home/ovh/src/gd-2.0.1
-I/usr/include/imap -I/usr/local/mysql/include/mysql -I/usr/include/pgsql -I/home/ovh/src/php-4.2.2/ext/xml/expat  -I/home/ovh/src/php-4.2.2/TSRM -g -O2 -prefer-non-pic -static   -o
libphp4.la -rpath /home/ovh/src/php-4.2.2/libs -rdynamic -L/home/ovh/src/gd-2.0.1 -L/usr/kerberos/lib -L/usr/local/mysql/lib/mysql -L/lib  -R /home/ovh/src/gd-2.0.1 -R
/usr/kerberos/lib -R /usr/local/mysql/lib/mysql -R /lib stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la
/home/ovh/src/php-4.2.2/ext/zlib/libzlib.la /home/ovh/src/php-4.2.2/ext/bcmath/libbcmath.la /home/ovh/src/php-4.2.2/ext/calendar/libcalendar.la
/home/ovh/src/php-4.2.2/ext/ctype/libctype.la /home/ovh/src/php-4.2.2/ext/db/libdb.la /home/ovh/src/php-4.2.2/ext/ftp/libftp.la /home/ovh/src/php-4.2.2/ext/gd/libgd.la
/home/ovh/src/php-4.2.2/ext/gettext/libgettext.la /home/ovh/src/php-4.2.2/ext/imap/libimap.la /home/ovh/src/php-4.2.2/ext/mysql/libmysql.la /home/ovh/src/php-4.2.2/ext/pcre/libpcre.la
/home/ovh/src/php-4.2.2/ext/pdf/libpdf.la /home/ovh/src/php-4.2.2/ext/pgsql/libpgsql.la /home/ovh/src/php-4.2.2/ext/posix/libposix.la /home/ovh/src/php-4.2.2/ext/session/libsession.la
/home/ovh/src/php-4.2.2/ext/standard/libstandard.la /home/ovh/src/php-4.2.2/ext/sysvsem/libsysvsem.la /home/ovh/src/php-4.2.2/ext/sysvshm/libsysvshm.la
/home/ovh/src/php-4.2.2/ext/xml/libxml.la TSRM/libtsrm.la -lgdbm -lpam -lcrypto -lssl -lc-client -lpq -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient -lcrypt -lpam -lgd -lfreetype -lpng
-lz -ljpeg -lz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ldl
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
    que faire svp ? mes options de compils sont: 
    ./configure --with-apache=../apache_1.3.26 --enable-trans-sid --with-jpeg-dir --with-gd=../gd-2.0.1 --with-tiff-dir --with-png-dir --with-zlib-dir --with-pdflib --enable-ftp
--enable-gd-native-ttf --with-freetype-dir=/usr/include/freetype2 --with-mysql=/usr/local/mysql --with-gettext --with-pgsql=/usr --with-imap --with-kerberos --enable-sysvsem
--enable-sysvshm --with-xml --with-db --enable-bcmath --enable-calendar --with-imap-ssl
    un ldconfig n'y change rien et 
    [ovh@ns355 php-4.2.2]$ ls -la /usr/lib/libgdbm*
-rw-r--r--    1 root     root        49782 jui 13  2000 /usr/lib/libgdbm.a
-rwxr-xr-x    1 root     root          642 jui 13  2000 /usr/lib/libgdbm.la
lrwxrwxrwx    1 root     root           16 sep 11  2001 /usr/lib/libgdbm.so -> libgdbm.so.2.0.0
lrwxrwxrwx    1 root     root           16 sep 11  2001 /usr/lib/libgdbm.so.2 -> libgdbm.so.2.0.0
-rwxr-xr-x    1 root     root        29050 jui 13  2000 /usr/lib/libgdbm.so.2.0.0
    HEEEEELPPP merci pour votre aide, promis c'est la premiere et dernière fois

    • [^] # Re: oui je sais sai mal

      Posté par  (site web personnel) . Évalué à -10.

      cool des -1 tres constructif

      • [^] # Re: oui je sais sai mal

        Posté par  (site web personnel) . Évalué à -4.

        et ca t'étonne ? Un post tres long et déconnecté du sujet (on parle d'une faille de sécu et mise à jour, ca ne transforme pas de fait les commentaires de linuxfr en forum de support d'aide pour PHP). [-1 car message perso]

        • [^] # Re: oui je sais sai mal

          Posté par  (site web personnel) . Évalué à -10.

          chuis pas non plus en train de demander où je peux trouver un script pour faire une gallerie de thumbnails en php (fr.comp.lang.php est devenu la tribune idéale pour ca) ... donc oui ça m'étonne car les endroits qui auraient été appropriés n'apportent aucune réponse...

          • [^] # Re: oui je sais sai mal

            Posté par  (site web personnel) . Évalué à -4.

            Ben ouais...

            Pas d'bol, c pas l'endroit.
            Question d'étique, ou de règles chais pas, moi j'aime bien comme ca.

            Je te souhaite tout de même d'aboutir dans tes recherches...

            (Debian GNU/Linux roulaize... ;)

    • [^] # Re: oui je sais sai mal

      Posté par  (site web personnel) . Évalué à 3.

      Juste un commentaire même si ce n'est pas du tout le lieu : Je ne vois aucune erreur dans ce que tu nous a copié collé malgré ta phrase qui le laissait penser.

  • # Rhaaaaaa(2)

    Posté par  . Évalué à -3.

    Qu'est ce qu'on est content quand sa distrib, ne se jette pas sur la dernière release sortie... </troll></-1>

    • [^] # Re: Rhaaaaaa(2)

      Posté par  (site web personnel) . Évalué à -5.

      ah ... un troll sur debian Ils en étaient au 4.0.3pl1 il y a encore quelques temps ? (qui avait lui aussi un probleme de sécu donc) [-1 car apres avoir marché dedans j'en ai plein les pieds]

      • [^] # Re: Rhaaaaaa(2)

        Posté par  . Évalué à 10.

        Pas mal comme troll :)
        Bien joué, malgrès tout, les versions debian sont remis à jour pour les problèmes de sécurité ou de bug.
        Si le package php-4.0.3pl1 n'a pas changé de nom ni de numéro de version, son contenu a été remanié. Le binaire a été patché et l'ensemble des packages recrées.
        Cela s'est passé de la même manière pour le package ssh. Ce dernier possédait un problème de secu. Un simple apt-get install ssh permettait de retélécharger la même version - même numéro - cependant le binaire était patché et le fichier de configuration modifié pour une sécurité accrues.

  • # Facile, upgradez vers tomcat 4.0.4

    Posté par  (site web personnel) . Évalué à -10.

    Depuis le temps que ca dure les trous dans php, faudrait peut être passer à un truc qui marche un jour.

    • [^] # Re: Facile, upgradez vers tomcat 4.0.4

      Posté par  (site web personnel) . Évalué à 10.

      Ah tu penses que tomcat marchera un jour sur le P100 avec 16Mo de RAM qui me sert de serveur web ? En tout cas PHP marche très bien...

    • [^] # Re: Facile, upgradez vers tomcat 4.0.4

      Posté par  (site web personnel) . Évalué à -2.

      "les" trous ? il n'y en a pas eu tant que ca tout de meme. Il y a beaucoup de bugs, ce qui est normal pour un soft jeun qui évolue beaucoup, mais des trous je pense que tu peux les compter sur les doigts d'une main. Bref, il y en a peut etre eu moins que dans ssh ou d'autres trucs qu'on a jamais remis en cause et qui sont plus critiques

    • [^] # Re: Facile, upgradez vers tomcat 4.0.4

      Posté par  . Évalué à -9.

      Buuurn, troll, burn!

    • [^] # Re: Facile, upgradez vers tomcat 4.0.4

      Posté par  . Évalué à -4.

      Depuis le temps que ca dure les trous dans php, faudrait peut être passer à un truc qui marche un jour.

      un truc qui marche avec Java?
      L.O.L

    • [^] # Re: Facile, upgradez vers tomcat 4.0.4

      Posté par  (Mastodon) . Évalué à 7.

      Pas facile de répondre à un troll sans marcher dessus. Enfin je me lance tout de même.
      Tous d'abords:
      Certe Tomcat est très robuste si le serveur est monstrueux et que le programme est très bien écrit.
      Il est plus facile de faire cohabiter plusieurs applis php que plusieurs applis tomcat.
      Les tests que j'ai fais ici sur un petit serveur me donnent de bonne performance en php jusqu'a 100 utilisateurs simultanés pour une grosse appli en php (ldap, mysql).
      le développement d'une petite appli php demande le 1/4 du temps.
      Toutes les distribs ont apache et php.
      Il y a énormement de source et d'appli dispo en php. (imp, phpgroupware, dacode ...)
      On peut l'interfacer avec plein de base de données (oracle, db2, informix, mysql, pgsql ...)
      Bref ca marche presque tout seul.
      Alors que les déploiements d'applis tomcat ca marche rarement aussi bien.

  • # ftp

    Posté par  (site web personnel) . Évalué à 10.

    Sur ftp://ftp.vhffs.org/dist-files/ il y a le .tar.gz et le tar.bz2 de la version 4.2.2, mais pas les patchs car c'est pas un mirroir. Accessoirement j'ai signé les archives ... comme ca vous savez sur qui tapper si c'est pas les bonnes ... mais ca remplace pas une vrai signature de la part de l'équipe de developpement de PHP. Et cela m'enerve grandement... comment avoir confiance dans leur produit ...

Suivre le flux des commentaires

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