Faille dans la gestion des acquitements par le protocole TCP

Le protocole TCP ("Transmission Control Protocol") permet aux applications de communiquer de manière fiable sur un réseau IP. Ce protocole possède des mécanismes de contrôle de congestion, définies dans la RFC 2581. Le principe du contrôle de congestion est d’éviter que trop de données ne soient envoyées en même temps sur le réseau.

Ce protocole prévoit que le client TCP acquitte (messages TCP de type ACK) les paquets envoyés par le serveur. Le serveur peut ainsi varier son taux de transmission en fonction des paquets ACK qu’il reçoit. Cette fonctionnalité repose sur le fait que le client et le serveur (l’émetteur et le récepteur) coopèrent pour la détermination de ce taux de transmission.

Il existe cependant une faiblesse protocolaire (CVE-2005-3675), que la RFC n'a pas prévue, appelée le "ACK optimiste" ("optimistic ACK") et offrant des possibilités d’attaques à un client TCP mal intentionné. Un paquet "ACK optimiste" est un paquet ACK envoyé par le client pour un segment de données qu’il n’a pas encore reçu.

Le problème vient du fait qu’un attaquant distant (client TCP mal intentionné) peut construire des paquets "ACK optimistes" avant d’avoir reçu les paquets envoyés par le serveur (l’émetteur). Ce dernier va donc croire que le transfert se passe mieux que dans la réalité et accélérer en conséquence son taux de transfert de paquets. En générant un train continu de "ACK optimistes", l'attaquant provoque une montée en puissance du serveur visé qui envoie alors de plus en plus rapidement ses données, jusqu'à la saturation de la bande passante réseau en amont de ce serveur. Il s'agit donc d'une attaque en déni de service (DoS) qui vise à épuiser la bande passante réseau du serveur attaqué. Un client malicieux peut mener cette attaque sur des serveurs web, FTP, P2P, etc…, en générant des "ACK optimistes" pendant le téléchargement de gros fichiers. Les auteurs de l'analyse technique indique qu'un attaquant utilisant une simple connexion Internet à 56K (modem RTC) peut déclencher par cette méthode des trafics de plus de 70 Mo/s sur les serveurs web visés.

Nota : Cette faille a été décrite pour la première fois en 1999 ("TCP Congestion Control with a Misbehaving Receiver") et reprise de manière plus détaillée en 2005 ("Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse").

Il est important de noter que rien n'est prévu dans la RFC pour empêcher l'utilisation de ACK "optimistes". Cette faiblesse est intrinsèque au protocole TCP et s'applique donc à tous les systèmes. Par exemple, Sun a explicitement indiqué que Solaris est vulnérable à ce type d'attaque (parce que ce système d’exploitation implémente strictement la norme TCP). Juniper vient de publier un bulletin de sécurité concernant ce problème (dont le lien est donné ci-dessous), indiquant que cette faille présente pour eux un risque très faible d’exploitation sur leurs produits réseau et garde-barrière (ces derniers n’utilisant que très peu d’applications TCP). N’ayant en outre pas trouvé de solutions concrètes à ce problème, Juniper ne prévoit pas le développement de solutions correctives pour cette vulnérabilité. Par contre, des propositions visant à modifier l’implémentation du protocole TCP ont été faites (notamment sous Linux) mais n’ont pas été validées par l’IETF.

Pour plus d’information :

• Archive de Bugtraq du 16 novembre 2005 : http://www.securityfocus.com/bid/15468
• Référence CVE : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3675
• Note de vulnérabilité de l’US-CERT VU#102014 : http://www.kb.cert.org/vuls/id/102014
• Bulletin de sécurité PSN-2005-12-004 de Juniper : http://www.juniper.net/support/security/alerts/PSN-2005-12-004.txt
• Papier de l’Université de Washington, Seattle (1999) : TCP Congestion Control with a Misbehaving Receiver
• Rapport technique UMD-CS-TR-4737 (2005) : Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse