Les dénis de service et les problématiques de disponibilité qu'ils impliquent sont devenus partie intégrante de notre paysage Internet. Toujours plus spectaculaires et importantes, ces attaques paralysent parfois d'importants sites web et des infrastructures critiques. Leurs causes sont multiples et on voit régulièrement de nouveaux mécanismes d'attaques, parfois combinés, qui, couplés à la topologie de nos réseaux et au nombre croissant d'objets connectés vulnérables, font peser une menace sérieuse pour beaucoup d'organisations.
Il y a maintenant un mois, des chercheurs de Netflix révélaient une vulnérabilité dans l'implémentation TCP de Linux. N'importe quelle machine avec le moindre port acceptant des connexions TCP peut alors se voir la cible d'une attaque. La vulnérabilité porte sur la manière dont l'implémentation TCP du noyau traite le Selective ACKnowledgement (SACK).
Quatre alertes ont alors été émises :
- CVE-2019-11477 : SACK Panic (Linux kernel >= 2.6.29), menant à un kernel panic (plantage système)
- CVE-2019-11479 : Excess Resource Consumption Due to Low MSS Values (toutes versions de Linux)
- CVE-2019-11478 : SACK Slowness (Linux < 4.15) or Excess Resource Usage (toutes versions de Linux)
- CVE-2019-5599 : SACK Slowness (FreeBSD 12)
L'impact le plus critique résulte d'un integer overflow , il s'agit du CVE-2019-11477 et se traduit par un kernel panic (crash du noyau paralysant le système).
Le second impact est dû à une complexité algorithmique dans l'implémentation du SACK et mène à une saturation des ressources de la cible pouvant provoquer de gros ralentissements. Ceci se produit en forçant une valeur faible du MSS (Maximum Segment Size) pour forcer la fragmentation des paquets et saturer les ressources de la cible. Il s'agit des CVE-2019-11479, CVE-2019-11478 et dans une moindre mesure sur FreeBSD 12 du CVE-2019-5599 (FreeBSD utilise RACK TCP stack mais pas par défaut).
À ce jour, il n'y a à notre connaissance pas de code d'exploitation disponible sur le Net, mais ceci n'est qu'une question de temps. Des chercheurs chinois semblent en tout cas s'y intéresser de près, ici avec packetdrill et Scapy , ou encore là . Il s'agit de ne pas paniquer mais de prendre très au sérieux cette menace, d'autant qu'il suffit d'exposer un service TCP pour que votre système soit potentiellement vulnérable.
Pour corriger cette vulnérabilité vous avez plusieurs options :
-
La première est la désactivation pure et simple de SACK, mais ceci aura nécessairement un impact négatif sur les débits maximum des sessions TCP, donc à éviter en production ;
-
La seconde et la meilleure option est d'appliquer un correctif à votre noyau (la majorité des grosses distributions proposent déjà des correctifs dans leurs versions stables) ;
-
Une autre solution est d'appliquer une règle au niveau de votre firewall afin de filtrer les paquets MSS de faible valeur, avec le risque de voir des sessions TCP mal fonctionner (coupure ponctuelles ou permanentes intempestives).
Du fait de manque de contournement global viable, la majorité des clouds a simplement diffusé une mise à jour de leurs logiciels de référence comme (l'AMI AWS) ou le build (Kubernetes de GKE)[ https://cloud.google.com/kubernetes-engine/docs/security-bulletins ]) puis s'en remet au bon vouloir de ses clients pour appliquer les correctifs et rebooter les VMs impactées.
Nous insisterons enfin sur le fait que si les effets "dans le monde réel", ne sont pas encore perceptibles, nous partons avec cette vulnérabilité pour plusieurs années de menace pesant sur des systèmes compliqués, voire impossibles à mettre à jour (smartphone, cameras ip, montres connectées, box android tv, matériels médicaux , équipements industriels...).
Si vous n'avez pas la culture DevOps, rebooter ou redéployer massivement des services risque de se présenter comme une tâche particulièrement longue et dangereuse. Si vous êtes chez Bearstech, vous n'avez pas ce problème... Vous n'avez même pas eu la conscience de l'avoir, nos équipes ayant déployé les patches sur 100% de son parc sans solliciter ses clients. C'est peut être le moment de tester votre prestataire en lui demandant un bulletin de situation à +1 mois sur l'incidence de "SACK Attack" sur vos plateformes !
