Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

Déni de service universel dans TCP

Bon, difficile d'y échapper, surtout à quelques jours de la diffusion des détails. Ce billet fait suite à l'annonce vu sur le blog des chercheurs de chez Outpost24 relatant une nouvelle faille dans le design du protocole le plus utilisé dans l'Internet.

Cette faille, si l'on en croit le peu qui a pu filtrer, porte sur la gestion de la machine à état de TCP. En amenant cette machine dans un certain état, il serait possible de bloquer de l'allocation mémoire sur le système cible, finissant par saturer sa mémoire. Ou bien de saturer sa bande passante. Seulement 200 packets par secondes seraient même suffisant. Tous les systèmes d'exploitation seraient affectés. Well. Want to see that.

Du coup, je me suis (re)penché sur des techniques aussi vieilles que Naphta, en y apportant certaines modifications. Je ne vais pas faire un billet complet sur Naphta, mais en gros, Naphta amène la pile TCP/IP cible soit dans l'état ESTABLISHED, soit dans l'état FIN_WAIT_1 pour accomplir sa sombre tâche de destruction.

Une des dernières hypothèses sur le sujet était une évolution de Naphta, avec en plus l'envoi d'un payload applicatif vers la cible. En n'acquittant pas la réponse obtenue à une requête applicative, la cible va réémettre de nombreuses fois sa réponse, saturant un peu plus sa bande passante ainsi que sa mémoire (le tampon de réponse n'étant jamais libéré).

Faisons un rapide calcul. Soit une adresse IP ouvrant 60 000 connexions vers un serveur Apache. Imaginons que chacune de ces connexions entraîne l'émission d'une réponse HTTP d'environ 2 ko (chiffre arbitraire, mais je le prends comme moyenne acceptable). 60 000 x 2, soit 120 Mo. Outre le fait que je vais me prendre 120 Mo de trafic dans la tronche, la cible risque fort de garder 120 Mo de tampon alloués en mémoire. Et oui, puisque je n'acquitterai pas (au sens TCP ACK), la cible va garder ça dans un tampon, et réémettre à certains intervalles ce packet (et encore me balancer 120 Mo dans la tronche).

Vous allez me dire : la cible supportera certainement 120 Mo dans sa mémoire et sur sa bande passante. Par contre moi ... Maintenant, multipliez ce nombre par 10. 10 machines lançant cette attaque. En cherchant un peu, il est possible (hypothèse de ma part) que les chercheurs en question utilisent plusieurs adresses IP sources pour leur attaque. D'abord pour contourner la limitation de bande passante de l'attaquant, ensuite pour contourner la limitation des 60 000 (65 535, en fait) connexions correspondant au tuple adresseSource,portSource,adresseDestination,portDestination. Là, on atteint 1 Go pour 10 IP. 10 Go pour 100 IP. Ca à l'air pas mal.

Ainsi, j'ai développé un programme en utilisant mon framework préféré (Net::Frame) pour tester l'efficacité des ces attaques. Mais comme ce soir, j'ai la flemme de mettre ça au propre, ce sera peut-être l'objet d'un autre billet.

Commentaires

1. Le dimanche, octobre 19 2008, 15:14 par pello

Hélas, pas de détails publiés à la T2.
Bravo pour l'ouverture de ton blog :)

Francois

2. Le dimanche, octobre 19 2008, 22:06 par Michel Arboi

Si c'est ça, quelle différence avec Naphta et ses avatars (netkill...)?
Leur attaque est censée être générique et s'en prendre à n'importe quelle ressource noyau. Je trouve étonnant que personne n'ait vu ça avant. Ce truc sent l'arnaque.

3. Le lundi, octobre 20 2008, 09:07 par GR

@pello: Et non, pas de détails. C'est vraiment ridicule. Tout ce buzz pour rien.

@Michel: Malheureusement, sans leurs détails, on va devoir arrêter les spéculations :(

Sinon, pour les intéressés, netkill.pl est ici:
http://securityvulns.ru/files/netki...

En gros, il fait le SYN, et répond ensuite au SYN+ACK avec un ACK+PSH contenant un payload applicatif (du HTTP). Il économise un packet, pas mal.

4. Le samedi, juin 20 2009, 12:24 par Michel Arboi

Ça ne serait pas ça, finalement?
http://www.phrack.org/issues.html?i...

5. Le mardi, juin 23 2009, 16:02 par GR

Apparemment, il y aurait une différence, d'après le CERT-FI :
https://www.cert.fi/haavoittuvuudet...

"June 15 2009. In the issue #66 of the Phrack magazine there was an article on exploiting TCP Persist Timer weaknesses (http://www.phrack.com/issues.html?i...) to cause Denial of Service conditions. The article discusses issues similar but not the same as the issues reported by Outpost24. The publication of the Phrack-magazine article will not affect the coordination and schedule related to the issues reported by Outpost24. CERT-FI emphasizes that the eventual release of the issues reported by Outpost24 will be done in a coordinated fashion."