Vulnérabilité sous ActivePerl

A la fin du mois de décembre 2001, une vulnérabilité concernant ActivePerl (package PERL distribué par la société ActiveState) a été publiée sur Internet (cf. l'URL donnée en fin d'article). Après analyse, il ne s'agit pas à proprement parler d'un problème ActivePerl, mais plutôt d'une mauvaise configuration de certains serveurs web Microsoft Internet Information Server (IIS) utilisant ce produit. Le même problème existe aussi pour d'autres applications interfacées avec IIS, et nous avons donc décidé de consacrer un article sur cet aspect de la configuration IIS.

Description de la vulnérabilité

Si un serveur web IIS utilisant ActivePerl est mal configuré, alors un utilisateur distant peut savoir à quel endroit sur la machine l'arborescence web a été installée. Il suffit pour cela qu'il tente d'accéder à un script PERL inexistant (par exemple "www.serveur.com/cgi-bin/fichier_inexistant.pl"). Le message d'erreur que lui retourne alors ActivePerl (typiquement "Can't open perl script "C:\Inetpub\wwwroot\cgi-bin\fichier_inexistant.pl": No such file or directory") lui indique en effet la localisation exacte du serveur Web (" C:\Inetpub "), ce qui peut-être une information utile pour une attaque ultérieure.

Analyse

Bien que le message d'erreur soit généré par ActivePerl, le problème n'est pas vraiment un problème relatif au produit lui-même, mais plutôt un problème dû à la façon dont IIS gère les applications interfacées avec le serveur web. Lorsqu'on déclare à IIS que certains fichiers doivent être traités par des applications tierces (via des extensions ISAPI ou des scripts CGI), IIS délègue en effet alors totalement à cette application tierce le traitement des requêtes correspondantes.

Ainsi si on déclare à IIS que tout script nommé " .pl " doit être traité (mappé) par ActivePerl, alors ActivePerl va être invoqué par IIS, même pour des fichiers Perl " .pl " inexistants. Il se produit alors typiquement le comportement décrit précédemment (ActivePerl génère un message " trop bavard " à propos d'un fichier " .pl " inexistant).

Ce même comportement existe également pour d'autres applications externes. Par exemple, taper une URL inexistante se terminant par " .ida " ou " .idq " (invocation des fonctionnalités " Index Server ") produit exactement le même type de message d'erreur trop " bavard ".

Recommandation

Pour éviter ce type de problème, il est possible de configurer IIS en lui demandant de vérifier que le fichier existe, avant d'appeler l'application externe correspondante.

Ce paramétrage se fait au niveau de l'écran de définition des " mappings " vers les applications externes (dans la section " Application_setting " du serveur Web tout entier -" Serveur_Web/Properties/Home_directory/"-, ou dans cette même section mais au niveau des propriétés du répertoire précis sur lequel le " mapping " aura été défini), en activant la boite à cocher " Check that file exist ". Il faut le faire individuellement au niveau de chacune des extensions.

Pour plus d'information

Vulnérabilité " Active Perl path reveal " publiée par Securityfocus : http://www.securityfocus.com/cgi-bin/vulns-item.pl?id=3770