Nombre de systèmes sont basés sur glibc qui est l'un des composants parmi les plus importants pour les systèmes Linux. Pour cause, glibc permet de gérer les appels système de bas niveau sur les distributions Linux comme par exemple l'ouverture de fichiers et l'allocation d'espace mémoire.

Début 2015, il avait été découvert dans cette bibliothèque GNU C une vulnérabilité critique baptisée Ghost (en rapport avec la fonction gethostbyname) et affectant les versions 2.2 à 2.18 de glibc. Un bug remontant à 2000 et non présent à partir des versions de glibc depuis mi-2013. Cela étant, cette faille concernant serveurs, routeurs et NAS Linux avait un indice CVSS de 10.0 (une dangerosité maximale), d'autant que peu de distributions intégraient les versions récentes de glibc.

Pas de petit nom flippant pour la vulnérabilité CVE-2015-7547 qui frappe de nouveau glibc. Découverte par des chercheurs en sécurité de Google et Red Hat, elle est considérée critique. Cette fois-ci, le bug a été introduit en mai 2008 et concerne les versions de glibc à partir de 2.9.

Le problème est de type dépassement de mémoire tampon dans le résolveur DNS côté client de glibc. Les machines Linux sont exposées à un risque d'exécution de code à distance lors de l'utilisation de la fonction getaddrinfo (obtenir les adresses IP associées à un hôte ou à un nom de domaine). Google évoque une exploitation avec des noms de domaine ou serveurs DNS contrôlés par des attaquants ou via une attaque de type man-in-the-middle.

Pour un chercheur de Red Hat cité par Threatpost, il est probable que " tous les serveurs Linux et les frameworks Web tels que Rails, PHP et Python soient affectés, ainsi que les applications Android exécutant glibc. "

Les chercheurs de Google parlent de vecteurs d'exploitation (pour déclencher le dépassement de mémoire tampon) comme ssh, sudo et curl, et ajoutent qu'ils sont divers et répandus. Néanmoins, l'exploitation afin d'obtenir une exécution de code à distance est jugée complexe et un patch a été élaboré.

Si des attaques n'ont pas été repérées, nul doute désormais que certains vont se pencher sérieusement sur la question avec les premiers détails qui filtrent. Pour les administrateurs et à défaut de ne pouvoir appliquer immédiatement le patch pour glibc, une mesure d'atténuation du risque consiste à " limiter les tailles des réponses acceptées par le résolveur DNS localement (avec un outil comme DNSMasq) et s'assurer que les requêtes DNS sont seulement envoyées à des serveurs DNS, ce qui limite la taille des réponses UDP. "

Google explique en effet que la vulnérabilité s'appuie sur une réponse UDP ou TCP de plus de 2048 octets qui est suivie par une autre réponse qui écrasera la pile.