LLM · tout ou partie
GHOST (CVE-2015-0235) est une vulnérabilité historique de glibc, la bibliothèque C du projet GNU utilisée par de nombreuses distributions Linux. Elle illustre un problème classique : corriger un bogue ne suffit pas si son importance pour la sécurité n’est pas reconnue et si le correctif ne parvient pas aux systèmes déployés.
Fiche complétée avec l’aide d’un LLM le 27 octobre 2026. La date de publication initiale est conservée.
Une bibliothèque au cœur du système
Une bibliothèque fournit des fonctions réutilisées par les programmes. La glibc intervient dans de nombreuses opérations courantes ; une faille peut donc concerner plusieurs applications sans se trouver dans leur propre code.
GHOST touche la fonction interne __nss_hostname_digits_dots(), accessible notamment par gethostbyname() et gethostbyname2(), des fonctions de résolution de noms. Un traitement incorrect de certaines entrées peut provoquer un dépassement de tampon dans le tas : des données sont écrites au-delà de la zone mémoire prévue. Le surnom GHOST vient de gethost. Avis Red Hat.
Ce qu’un attaquant pouvait obtenir
Selon l’application, son exposition et les conditions d’exécution, un attaquant pouvait provoquer un plantage ou parvenir à exécuter du code avec les droits du processus vulnérable. Une glibc vulnérable ne signifiait donc pas que chaque service était automatiquement exploitable à distance, ni que l’attaquant obtenait systématiquement les droits root. Il fallait qu’une entrée contrôlée atteigne le chemin de code concerné. Analyse Cisco.
Pourquoi le correctif a-t-il tardé à arriver ?
- 2000 : la version glibc 2.2 introduit le défaut.
- 21 mai 2013 : correction dans le projet glibc, avant la version 2.18, sans classement comme problème de sécurité.
- 27 janvier 2015 : Qualys divulgue GHOST avec les distributions concernées ; des mises à jour de sécurité sont alors diffusées.
L’ancienne formule « détectée puis… rien » était donc trop sommaire. Le problème avait été corrigé en amont, mais sa portée sécuritaire n’avait pas été identifiée, et plusieurs distributions stables ou à support long conservaient le code vulnérable. C’est cette distinction entre correction amont et déploiement des correctifs qui explique le décalage. Annonce Qualys du 27 janvier 2015.
Comment vérifier et corriger
Pour une machine ancienne, consulter l’avis de son fournisseur et vérifier la version complète du paquet installé : une distribution peut avoir rétroporté le correctif tout en conservant un numéro de glibc antérieur à 2.18. Le numéro amont seul n’est donc pas un verdict fiable.
Après mise à jour, les processus utilisant encore l’ancienne bibliothèque doivent être relancés. Pour les exécutables liés statiquement, remplacer la bibliothèque partagée ne suffit pas : il faut également reconstruire ou mettre à jour le programme. Sur un système non maintenu, une migration est préférable à l’accumulation de correctifs isolés. Fiche CERT/CC.
À retenir
GHOST n’est pas une faille de WordPress ni du noyau Linux : c’est une faille de bibliothèque système dont l’impact dépend des programmes qui l’utilisent. L’inventaire des dépendances, la qualification des correctifs et le redémarrage effectif des services font partie intégrante du traitement d’une vulnérabilité.