Nouvelle faille critique dans la glibc ! A vos patchs !

0 commentaires

Présentation

Les équipes de RedHat et Google ont découvert de façon indépendante un nouveau bogue dans la glibc, moins d’un an après la fameuse faille GHOST.

Ce bogue porte sur une portion du code qui s’occupe des requêtes DNS, il est présent dans toutes les versions depuis la 2.9 (mai 2008) et a pour identifiant le CVE-2015-7547 avec un ranking 8.1/10 (High) selon le CVSS 3.0.

La glibc est ce que l’on appelle un « stub resolver » dans l’architecture DNS. Grossièrement, la librarie pose une question, elle obtient une réponse. Cette librairie est au centre de Linux, par exemple lorsque vous utilisez « cat » vous utilisez la glibc.

DNS est également au centre de l’architecture Internet. Sans DNS, peu de choses fonctionnent !

En outre, l’équipe Google a démontré la possibilité de réaliser une exécution de code arbitraire à distance, malgré la présence de mesures de mitigations comme l’ASLR ou le NX mais dans un contexte technique favorable (pas de serveur cache DNS).

Logiciels affectés

De nombreux logiciels sont affectés et c’est bien cela qui fait que ce bogue est particulièrement impactant.

Des logiciels comme « sudo », « ssh », « curl » sont vulnérables et comme le précise Dan Kaminsky dans son billet, des vulnérabilités dans sudo c’est du déjà vu, des vulnérabilités permettant une exécution de code à distance dans sudo, beaucoup moins !

Des langages de haut-niveau, dits également « memory-safe » sont également impactés comme PHP, Ruby on Rails, JavaScript ou Python pour ne citer qu’eux, car ils utilisent la glibc.

Android ne l’est pas car il utilise une librairie différente de la glibc, appelée bionic. De la même façon des périphériques embarqués type routeurs utilisent uclibc et ne sont pas concernés.

La vulnérabilité

Il s’agit donc d’une faille de type débordement sur la pile dans les fonctions send_dg() et send_vc() de la librairie libresolv et plus précisement dans le code responsable de réaliser des requêtes A/AAAA. Le problème est (à priori) uniquement valable lorsque libresolv est appelé depuis nss_dns, module du service NSS.

La glibc réserve 2048 octets dans un buffer sur la pile (stack) grâce à alloca() pour les réponses DNS. Dans send_dg() et send_vc(), si la réponse est supérieure à 2048 octets, un nouveau buffer est alloué sur le tas (la heap).

Mais dans certaines conditions, il y a une confusion entre le buffer sur la pile (stack) et le buffer nouvellement alloué sur le tas… causant un stockage de la réponse DNS dans le buffer sur la pile même si sa taille est supérieure à celle du buffer.

Ainsi, il est possible de profiter du bogue en transmettant une réponse DNS spécialement forgée qui déclenche un appel à la fonction getaddrinfo. L’attaque est réalisée en plusieurs étapes :

  • un buffer est rempli avec 2048 octets de données par une réponse DNS
  • le stub resolver recommence pour X raisons
  • Deux nouvelles réponses sont « stackées » dans le même buffer (espace temporaire de stockage de données sur la pile) avec plus de 2048 octets. Ce buffer est donc débordé.

Comme abordé, l’attaquant doit :

  • soit avoir le contrôle d’un serveur DNS malveillant
  • soit être en position de Man-In-The-Middle sur le réseau et être en capacité d’injecter/de modifier des réponses DNS

Stratégies de réduction du risque

Bien que Google ait démontré une attaque pratique, dans une architecture DNS directe (stub resolver -> serveur DNS autoritaire et malveillant) cela semble beaucoup moins « facilement » réalisable (et à l’heure actuelle ..) dans le contexte d’une architecture DNS plus classique (stub resolver -> serveur DNS cache récursif -> serveur DNS autoritaire et malveillant).

La meilleure stratégie est le patching mais cela nécessitera sans doute un redémarrage du serveur (ou une identification puis un restart de tous les services affectés, opération quand même assez lourde et incertaine !). Toutefois, il est nécessaire de ne pas attendre que de vraies attaques pratiques sortent et passent les serveurs caches DNS. Des éditeurs comme CheckPoint par exemple ont sorti des signatures IPS permettant de mitiger les risques. Nous n’avons pas encore étudié la qualité de ces signatures.

En revanche, toute les limitations de taille que l’on pourrait envisager au niveau par ex. de composants d’infrastructure (i.e. firewalls) pour mitiger les attaques risqueraient de briser des composants de façon non maîtrisée et cela n’est pas du tout recommandé !

Conclusion

Ce bogue n’est pas encore activement exploité mais il est particulièrement critique. Pour des composants transverses comme la Glibc, des stratégies de patching spécfiques devraient être définies. Ainsi, nous vous recommandons de patcher le plus rapidement possible … en attendant la prochaine faille ? 😉

 

Sources

 

Facebooktwitterlinkedin