GHOST pour les nuls, la vulnérabilité décrite en 10 questions/réponses

Le 27 janvier en fin de journée, Qualys a divulgué une vulnérabilité critique identifiée au sein de la bibliothèque GNU Libc (Glibc) [1] [2]. Son exploitation permet à un attaquant de prendre le contrôle d’un système à distance. Elle a été baptisée Ghost.

Étant dotée d’un joli nom et accompagnée d’un logo, cette faille a été fortement médiatisée. Retour en dix questions/réponses sur cette faille.

1. Qu’est-ce que la Glibc ?

La Glibc est la bibliothèque standard C proposée par le projet GNU. Elle contient les principales fonctionnalités requises pour faire tourner correctement un système Unix, ainsi que des extensions utilisées pour des développements dans le cadre du projet GNU. Cette bibliothèque est utilisée par la plupart des systèmes Linux.

2. D’où provient la vulnérabilité ?

La faille de sécurité référencée CVE-2015-0235 provient d’une erreur au sein de la fonction __nss_hostname_digits_dots() , uniquement utilisée au sein des fonctions gethostbyname() , gethostbyname2() , gethostbyname_r() ou encore gethostbyname2_r() .

Toutes ces fonctions sont définies au sein de la Glibc. En spécifiant des arguments spécialement choisis lors d’un appel à l’une des fonctions de la famille gethostbyname* , un utilisateur malveillant serait en mesure de provoquer une corruption de la mémoire via un débordement de tampon sur le tas, résultant potentiellement en la compromission du système.

3. Comment savoir si mon système est vulnérable ?

Le site Cyberciti.biz [3] propose plusieurs solutions afin d’identifier les systèmes concernés par Ghost.

  • Il est possible de lister les applications actuellement exécutées sur un système et tirant parti de la Glibc au moyen de la ligne de commande suivante :

lsof | grep libc | awk '{print $1}' | sort | uniq

  • Il est également possible de connaître la version utilisée de Glibc via la commande suivante :

ldd --version

Cette seconde commande permet de retrouver rapidement le numéro de version de la Glibc actuellement installée sur le système. Cependant, de par le mode de fonctionnement des principales distributions Linux, le numéro de la version corrigée de la Glibc peut varier. Pour faciliter la chose, une liste des distributions Linux vulnérables a pu été établie :

  • RHEL (Red Hat Enterprise Linux) version 5.x, 6.x et 7.x
  • CentOS Linux version 5.x, 6.x & 7.x
  • Ubuntu Linux version 10.04, 12.04 LTS
  • Debian Linux version 7.x
  • Linux Mint version 13.0
  • Fedora Linux version 19 et ultérieurs
  • SUSE Linux Enterprise 11 et ultérieurs
  • Arch Linux avec Glibc en version inférieure ou égale à 2.18-1

Enfin, un petit outil écrit en C a été publié par Qualys. Celui-ci permet de tester localement un système afin de savoir si ce dernier est vulnérable ou non.

Ce code est disponible à l’adresse suivante :

4. Pourquoi cette vulnérabilité a-t-elle été baptisée GHOST ?

La faille est référencée CVE-2015-0235, mais, afin de l’identifier plus facilement, un nom plus simple lui a été donné. Il provient d’une contraction du nom des fonctions vulnérables de la Glibc : gethostbyname* .

5. Depuis combien de temps est-elle présente dans la Glibc ?

Cette vulnérabilité a été introduite dans la version 2.2 de la Glibc, publiée en 2000 [4].

Cette faille aurait été initialement corrigée au sein de la version 2.15 [5] de la Glibc, publiée en décembre 2011 [6]. Cependant, à cette époque, le problème corrigé n’aurait pas été identifié comme étant une faille de sécurité, et n’aurait pas été remonté comme tel aux éditeurs intégrant la Glibc dans leurs distributions. La faille a donc été réintégrée par erreur dans les versions suivantes, actuellement intégrées dans les distributions.

6. Comment cette faille a-t-elle été découverte ?

Cette faille a été découverte par des chercheurs travaillant pour Qualys [7], et a été divulguée de manière responsable auprès du projet GNU éditant la Glibc, ainsi que des éditeurs des principales distributions Linux.

Ces derniers ont été alertés de l’existence de cette faille le 18 janvier dernier, afin de leur laisser le temps de préparer les correctifs et de les rendre disponibles aux internautes. D’après les informations disponibles, Qualys aurait découvert cette faille de sécurité il y a plus de 3 mois (avant le 2 octobre 2014) [8].

7. Quels outils sont vulnérables ? Dois-je patcher en urgence ?

Le mécanisme de résolution de nom DNS étant utilisé dans un nombre très important de logiciels, et la Glibc étant un des composants de base constituant un système GNU/Linux, un nombre très important de serveurs pourrait être vulnérable à des attaques distantes, sans authentification préalable. Cela inclut en particulier l’ensemble des distributions Linux : Debian, Ubuntu, Red Hat, CentOS, Slackware, Fedora, ou encore SuSE…

Cependant, la technique d’exploitation de la faille n’est pas clairement définie, et est spécifique à chacun des services exposés sur un réseau (SSH, MySQL, Apache, …).

D’après les travaux de recherche réalisés par Qualys, actuellement, seul le serveur Exim serait réellement vulnérable à l’exploitation de cette faille. L’utilisation des fonctions vulnérables au sein de services les plus courants ne serait pas possible, de par les spécificités de chacun de ces logiciels.

La liste des logiciels considérés comme étant non vulnérables [9] [10] est la suivante : Apache, Cups, Dovecot, Gnupg, ISC-Dhcp, Lighttpd, MariaDB/MySQL, Nfs-utils, Nginx, Nodejs, OpenLDAP, OpenSSH, Postfix, Proftpd, Pure-ftpd, Rsyslog, Samba, Sendmail, Sysklogd, Syslog-ng, tcp_wrappers, Vsftpd, Xinetd, Squid (avec squidpurge / cachemgr.cgi).

8. La vulnérabilité est-elle exploitée sur Internet ? Existe-t-il des codes d’exploitation ?

Aucune exploitation de la vulnérabilité n’a pour l’heure été observée, mais il pourrait ne s’agir que d’une question de temps.

En effet, à ce jour, aucun code d’exploitation n’est disponible pour tirer parti de cette faille et ainsi prendre le contrôle d’un système à distance. Qualys a annoncé disposer d’un outil permettant de prendre le contrôle d’un serveur Exim à distance. Cependant, ce code ne sera publié que lorsque Qualys estimera que la majorité des systèmes exposés sur Internet seront corrigés. L’éditeur a cependant publié un outil permettant de tester localement si un système est vulnérable. Celui-ci ne permet pas de prendre le contrôle du système.

9. Dois-je redémarrer mon serveur pour appliquer la mise à jour ?

Oui, en plus d’installer la mise à jour à l’aide de votre gestionnaire de paquet préféré (Apt, Aptitude, Yum, …), il est fortement recommandé de redémarrer le système afin de corriger la vulnérabilité.

10. Cette vulnérabilité est-elle plus critique que Heartbleed ou Shellshock ?

Cette question nous a été posée à plusieurs reprises. Le degré de criticité de la prise en compte de cette faille dépend très fortement du contexte dans lequel est utilisé le composant vulnérable. Cependant, la criticité de cette faille est incomparable par rapport aux deux autres vulnérabilités. En effet, de très nombreux services exposés sur Internet étaient vulnérables et des codes d’exploitation publics permettaient d’exploiter ces failles en quelques minutes…

Cette vulnérabilité est, certes, importante de par le nombre de systèmes concernés. Cependant, la surface d’attaque est relativement réduite, la technique d’exploitation (qui est spécifique à chacun des logiciels vulnérables) n’a pas été précisée, et aucun code d’exploitation n’est disponible [11].

Nous vous recommandons donc l’installation des correctifs, mais cela doit être réalisée de manière adaptée, en prenant en compte les impératifs métiers, et les processus de déploiement de correctifs interne à votre entreprise.

Mise à jour du 30 janvier 2015

De nombreux chercheurs se sont penchés sur la faille de sécurité afin de déterminer ses impacts réels. Ultra médiatisé, il s’avère que la faille n’affecte en réalité que peu de logiciels.

Par ailleurs, Oracle et Slackware ont publié des mises à jour pour leurs distributions respectives.

Logiciels vulnérables

A ce jour, après une analyse de nombreux logiciels utilisant la famille de fonctions vulnérables « gethostbyname », quatre nouveaux logiciels disponibles sur Linux ont été identifiés comme étant réellement vulnérables à cette faille. [12] La liste actuelle des logiciels vulnérables est donc la suivante :

  • clockdiff
  • procmail (au travers des fonctionnalités comsat/biff)
  • pppd
  • Exim (lorsque les options « helo_verify_hosts » et « helo_try_verify_hosts » sont activées, ce qui n’est pas le cas par défaut)
  • Interpréteur PHP (une fonctionnalité similaire est disponible au travers de la fonction « Zend_Validate_EmailAddress() » du framework Zend)

Enfin, les sites utilisant WordPress seraient aussi vulnérables à GHOST, étant donné que la page « xmlrpc.php » présente par défaut utilise elle aussi la fonction « gethostbyname() » à travers sa fonctionnalité de « pingback ».

Preuves de concept et codes d’exploitation

Par ailleurs, depuis la divulgation de Ghost, différentes preuves de concept ou code d’exploitation ont été publiées sur Internet.

Ainsi, une preuve de concept permettant de savoir si votre interpréteur PHP est vulnérable été publiée. Il suffit d’exécuter la commande suivante :

php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }'

Si un message d’erreur est affiché, alors votre système est vulnérable.

L’interpréteur PHP étant vulnérable, les sites utilisant le CMS WordPress [13] pourraient également être vulnérables à Ghost, étant donné que la page « xmlrpc.php » présente par défaut tire parti de la fonction « gethostbyname() » au travers de la fonctionnalité de « pingback ». Une preuve de concept permettant de savoir si votre installation est vulnérable est d’ores et déjà disponible [14].

Enfin, un code d’exploitation ciblant le serveur de messagerie Exim est également disponible publiquement. Ce dernier ne permet cependant pas de prendre le contrôle du serveur, mais uniquement de provoquer un déni de service [15].

En cadeau Bonus, les Références éditeurs :

Adrien Guinault

Découvrir d'autres articles