Mécanisme des Syn_Cookies

Ce mois-ci, une vulnérabilité de filtrage liée aux "SYN-cookies" a été publiée par plusieurs distributions Linux. Le Cert-IST a décidé de ne pas publier d'avis sur cette faille car :

• le mécanisme de SYN-cookie n'est pas actif par défaut sur Linux,
• les conditions d'attaques pour exploiter cette faille sont tout à fait particulières.

Nous profitons cependant de ce Bulletin pour faire un point sur la technique des SYN-cookies et sur la vulnérabilité associée.

Principe des SYN-cookies :

Le mécanisme des SYN-cookies a été imaginé comme une réponse aux attaques de type "SYN-flood". Dans une implémentation classique (sans SYN-cookie), le serveur TCP place dans une file d'attente toutes les nouvelles demandes de connexions reçues (réception d'un paquet SYN). Cette file permet au serveur de vérifier lorsqu'il reçoit le paquet suivant que le " hand-shake " en trois phases a bien été respecté.

L'attaque par "SYN-flood" consiste à saturer cette file des connexions en cours d'établissement qui a une taille limitée. Ainsi, à l'origine, la plupart des implémentations limitaient à moins de 10 la taille de cette file, et l'envoi de 10 paquets SYN suffisait alors à bloquer pendant plusieurs minutes le port réseau correspondant (les nouvelles demandes de connexion sont rejetées tant que la file est pleine).

Le principe du "SYN-cookie" consiste à supprimer cette notion de file. Lorsqu'une demande de connexion arrive (arrivée d'un paquet SYN), au lieu de retourner un ISN aléatoire (Initial Sequence Number sur 32 bits), le serveur retourne un ISN dont 24 bits contiennent un marqueur (le cookie). Si le paquet suivant renvoyé par le client contient toujours ce marqueur, le serveur en déduit que le handshake a bien été respecté et place la communication dans l'état "communication établie". La file d'attente des connexions en cours n'est donc plus nécessaire, et l'attaque consistant à saturer cette file ("SYN-flood") devient ainsi caduque.

Bien que tout à fait efficace, le mécanisme de SYN-cookie a généré de nombreuses discussions, et n'est proposé, à notre connaissance, que par les systèmes Linux, comme une option de configuration (non active par défaut). De plus, Linux n'adopte le comportement "SYN-cookie" que lorsque la file normale des connexions en cours d'établissement est saturée (car le "SYN-cookie" a l'inconvénient de rendre impossible la négociation de options TCP).

Vulnérabilité induite par les SYN-cookies :

Si le cookie choisi par le serveur peut-être deviné (ou plus exactement, si le client est capable de faire suffisamment d'essais dans un laps de temps donné), un attaquant peut envoyer directement un SYN-cookie fabriqué de toute pièce qui sera reconnu comme valide par le serveur. Dans ce cas, une connexion TCP est établie sans qu'aucun paquet SYN n'ait jamais été envoyé (cette étape a été sautée).

Le paquet SYN est souvent utilisé pour implémenter des règles de filtrage (par exemple pour autoriser un flux TCP en sortie, mais l'interdire en entrée). Dans le cas où l'on peut établir une connexion TCP sans émettre de paquet SYN, il est clair alors que le principe de ce filtrage est mis en défaut.

La vulnérabilité est donc que dans les implémentations de type SYN-cookie il est possible de contourner un filtrage basé sur les paquets SYN en effectuant un essai "par force brute" de tous les SYN-cookie possibles. La solution qui a été apportée par les nouvelles versions du noyau Linux est de ne plus adopter la protection "SYN-cookie" sur les ports pour lesquels un filtrage "SYN" est effectué (cette protection "SYN-cookies" n'aurait d'intérêt que pour se protéger d'une attaque "SYN-flood" venant d'une source autorisée par le filtrage).

Conclusion

Cette vulnérabilité montre tout d'abord comment deux bonnes idées (le "SYN-cookie" pour se protéger contre le "SYN-flood", et le filtrage "SYN") peuvent être incompatibles entre elles. Elle n'est possible cependant que dans des conditions tout à fait particulières.

L'attaquant doit :

• choisir une cible ayant activé le SYN-cookie et effectuant un filtrage par "SYN".
• disposer d'une bande passante importante pour pouvoir depuis une source unique (ou N sources étroitement concertées) attaquer "en force brute" le SYN-cookie.
• provoquer une condition de "SYN-flooding" (pour que le comportement "SYN-cookie" soit activé) en parallèle de l'attaque en force brute.

Cette vulnérabilité montre enfin, qu'il vaut mieux éviter de cumuler plusieurs fonctions sur le même équipement physique (ici : la protection contre le flooding et le filtrage des flux autorisés).

Pour plus d'information

• SYN-cookies - http://cr.yp.to/syncookies.html
• Vulnérabilité de SYN-cookies - http://www.securityfocus.com/bid/3505