Naptha : Déni de service sur les piles TCP-IP

Le 30 novembre dernier, le CERT-CC a émis un avis (CA-2000-21 : Denial-of-service vulnerabilities in TCP/IP Stacks), concernant la possibilité de saturer une machine cible en établissant un grand nombre de connexions TCP simultanées.

Le groupe "RAZOR Security Team", qui a exploré ce déni de service, a baptisé cette vulnérabilité "Naptha".

Le CERT-IST a choisi de ne pas émettre d'avis sur cette vulnérabilité. Le présent article décrit le problème identifié par "RAZOR security Team" et l'analyse du CERT-IST quant à sa criticité.

Description de la vulnérabilité

Pour gérer les connexions TCP, les systèmes d'exploitation doivent conserver en mémoire de l'information sur chacune des connexions en cours, et en particulier l'état de la connexion (par exemple : LISTEN, SYN RECD, SYN SENT, ESTABLISHED, etc..). Plus le nombre de connexion TCP est élevé, plus la quantité de ressources consacrée par le système d'exploitation à cette gestion est grande. Dans des cas extrêmes (par exemple plusieurs milliers de connexions simultanées), il est donc possible de saturer une machine en créant trop de connexions TCP.

Un attaque similaire bien connue dans ce domaine est le cas du "SYN flooding". Tous les systèmes d'exploitation imposent une limite au nombre de connexions TCP en cours d'établissement (phase pendant laquelle le "handshake" en 3 états est réalisé : SYN / SYN+ACK / ACK). Un attaquant peut alors facilement réaliser un "SYN flooding" en envoyant un nombre de paquets SYN suffisant pour atteindre le maximum de connexions en cours d'établissement autorisé. Dans ce cas, les demandes de connexion suivantes sont ignorées et le service TCP correspondant devient inaccessible sur la machine victime.

Le cas de Naptha est différent de l'attaque "SYN flooding" (cf. http://www.cert.org/advisories/CA-1996-21.html) . Ici, ce n'est pas la limite du nombre maximum de connexions en cours d'établissement qui est exploité (cas du SYN-flooding), mais la limite plus générale du nombre de connexions TCP en cours. Pour illustrer ce problème, on peut le comparer au cas où plusieurs milliers de connexions TELNET sont en cours sur une machine cible : cette machine a alors de fortes chances de ne pas supporter cette charge, parce que sa CPU ou sa RAM seront saturées.

Pour explorer cette possibilité, "RAZOR Security Team" a développé un outil qui crée des connexions TCP avec une machine cible, puis abandonne ces connexions en l'état. En testant cet outil, il a été effectivement constaté qu'il était possible de saturer de nombreux systèmes d'exploitation dont : Windows NT, Windows 9x, Solaris7&8, AIX4.3 et HP-UX11.0.

Analyse du CERT-IST

Le problème analysé par "RAZOR Security Team" est réel, et nous ne doutons pas que l'on puisse saturer une machine cible en créant un trop grand nombre de connexions TCP

Cependant, à notre sens, il n'y a pas vraiment ici de vulnérabilité car toute machine a une limite, liée en particulier à sa puissance matérielle. On pourrait ainsi imaginer qu'un pirate disposant de suffisamment de postes compromis, sature un serveur Web de requêtes tout à fait légitime.

Le réel problème est de savoir si l'outil mis en œuvre pour tester Naptha est dangereux. Il le serait si par exemple :

• il était largement diffusé,
• et s'il permettait à une simple machine ayant un accès Internet de saturer un site arbitraire.

Aujourd'hui, aucune de ces conditions n'est réunie :

• l'outil, réalisé par "RAZOR Security Team" à des fins de test, n'a été diffusé que vers le CERT-CC,
• l'outil se compose de deux modules (Le premier initialise des sessions TCP en utilisant des adresses sources usurpées. Le second s'occupe de maintenir ouvertes les sessions TCP initialisées), et le second module doit se trouver sur le même réseau que les adresses usurpées.

De plus, le risque de "consommation de ressources" lié à la vulnérabilité a été qualifié de "limité" par le CERT-CC, et nous partageons ce jugement.

Sur la base de cette analyse, le CERT-IST a donc décidé de ne pas émettre d'avis sur la vulnérabilité Naptha. Cependant :

• nous resterons vigilants sur les discussions et les évolutions potentielles de ce problème. En particulier si des exploitations réelles de cette vulnérabilité apparaissaient, un avis serait émis.
• pour les systèmes d'exploitation qui le permettent, il est important d'ajuster les paramètres TCP-IP (comme "TCP timeouts" ou "TCP keepalives") de façon à limiter l'exposition de ces machines à ce type de vulnérabilité.

Informations complémentaires