Après Ghost en janvier 2015, une nouvelle faille a été découverte sur la Glibc des serveurs Linux ! Arrêtons-nous un instant pour comprendre son fonctionnement.

Qu’est-ce que la Glibc ?

Lorsqu’une requête est envoyée à un programme, il utilise une ou plusieurs fonctions, stockées dans des bibliothèques, pour arriver au résultat demandé. Certaines de ces bibliothèques, contenant des fonctions de base, sont partagées par plusieurs programmes : c’est le cas de la Libc.

La Libc utilisée dans les systèmes Linux a été créée par le groupement GNU, qui l’a baptisée Glibc. C’est dans cette bibliothèque que se trouve le bug découvert récemment par des chercheurs de Google et Red Hat.

Pour une explication plus en profondeur de la Glibc, retrouvez notre article sur la faille Ghost.

La faille de sécurité : un buffer overflow dans la résolution DNS

DNS iconeLe bug trouvé est contenu dans toutes les versions de la Glibc à partir de la version 2.9. Il s’agit d’un buffer overflow (qu’est ce qu’un buffer overflow) dans la résolution DNS (Domain Name Server ou Serveur de Nom de Domaine) de la machine client, permettant l’exécution de code à distance. Explications :

Lorsqu’un internaute souhaite aller sur un site dont il connaît le nom de domaine, par exemple www.nbs-system.com, sa machine va interroger un serveur DNS afin d’obtenir l’adresse IP correspondante au site souhaité. Elle pourra alors ensuite se connecter directement à l’adresse IP pour accéder au site demandé.

Par défaut, les machines réservent un espace fixe de 2048 octets pour accueillir les réponses du serveur DNS. Une adresse IP étant composée de 4 octets, il y a donc de la place pour 512 adresses dans la réponse. Même si certains sites enregistrent de nombreuses adresses IP, la réponse peut donc largement être contenue dans cet espace de mémoire.

Si une réponse dépasse 2048 octets, alors la machine créera un deuxième espace de mémoire dédié à la réception de la partie excédentaire de la réponse. Il ne semble donc pas y avoir de risque.

Cependant, sous certaines conditions, la machine n’utilisera pas ce deuxième espace de stockage. Si la réponse dépasse la limite, alors les 2048 premiers octets seront enregistrés sur le premier espace, et les octets suivants seront stockés directement à la suite de celui-ci, en écrasant le code déjà présent : c’est le buffer overflow.

code attackPiratage informatique en action

Pour pouvoir exploiter cette faille de sécurité web, un pirate informatique doit avant tout remplir l’une des trois conditions suivantes :

  • Avoir le contrôle d’un serveur DNS
  • Être en position de « man-in-the-middle » entre l’internaute et un serveur DNS, pour pouvoir réécrire à la volée les réponses de ce dernier avant leur réception par l’internaute
  • Avoir un site web et gérer son propre serveur DNS (dans ce cas, la requête de l’internaute comme la réponse du serveur doivent passer par de nombreux serveurs intermédiaires, rendant moins facile la réussite de l’attaque).

Une fois l’une de ces conditions remplie, le pirate est libre d’écrire des réponses de la forme suivante : « 2048 octets (exemple : adresses IP) » + « lignes de code choisies ». L’objectif est que cette deuxième partie contenant des lignes de code soit écrite directement à la suite de l’espace mémoire réservé, en remplacement du code déjà présent sur la machine. C’est la fondation de ce qui permettra au pirate d’exécuter du code à distance.

Mais pour cela, il ne faut pas que la machine enregistre l’excédent de la réponse dans le deuxième espace de mémoire prévu ! Il faut donc que le pirate effectue quelques actions en plus. Les chercheurs de Google, afin de ne pas faciliter l’exploitation de la faille, n’ont pas précisé exactement ces actions, indiquant seulement l’existence de vecteurs tels que sudo, ssh ou curl.

man in the middle attackOn peut également noter un risque supplémentaire : nous avons parlé, jusqu’à présent, de la machine d’un internaute. Cependant, l’exploitation de cette faille peut être faite à plus grande échelle. Si une entreprise utilise un serveur DNS intermédiaire, faisant le relais avec un serveur DNS de FAI (Fournisseur d’Accès à Internet), c’est ce serveur qui peut être piraté. Les réponses étant ensuite relayées à l’ensemble des machines du réseau interne à l’entreprise, ces dernières tombent également sous le contrôle de l’attaquant : il a fait d’une pierre une multitude de coups.

Dans le cas où un pirate gère son propre serveur DNS pour son site, il peut agir à plus grande ampleur encore : en faisant passer sa réponse par des serveurs intermédiaires, il augmente le risque que son attaque soit bloquée, mais si elle réussit, la réponse a de grandes chances d’être gardée en cache, et donc d’être envoyée à toutes les machines tentant de se connecter à son site. Couplée à une opération d’ingénierie sociale, une attaque comme celle-ci peut rapidement prendre de l’ampleur.

Conclusion : l’attaque en elle-même peut avoir des conséquences très larges, et son exploitation n’est pas spécialement compliquée techniquement. Le frein ici, ce sont les conditions à remplir par le pirate pour se mettre dans une position où l’attaque est possible.

linux_patchSe protéger de la faille Glibc

Une seule solution : appliquer le patch correctif.

Sécurité Glibc/DNS : pour aller plus loin

Si vous souhaitez en savoir plus sur la faille, consultez les deux articles suivants :

L’article publié par Google sur son blog

Un excellent article de Franck Denis sur le sujet

Source technique : Mathieu Deous

Lucie Saunois
Lucie Saunois
Passionnée d'informatique, en particulier de sécurité, depuis qu'elle a rejoint l'OT Group en 2015, Lucie se spécialise dans la vulgarisation technique pour permettre à tous d'appréhender ces sujets parfois complexes.