La soci\u00e9t\u00e9 Anthropic a r\u00e9v\u00e9l\u00e9 une vuln\u00e9rabilit\u00e9 critique (CVE-2026-98432) dans la pile TCP du noyau Linux, permettant l'ex\u00e9cution de code \u00e0 distance via l'envoi de paquets sp\u00e9cialement format\u00e9s. Un exploit fonctionnel a \u00e9t\u00e9 cr\u00e9\u00e9, permettant d'ex\u00e9cuter du code au niveau du noyau et d'obtenir \u00e0 distance les droits root dans le syst\u00e8me. L'exploit pr\u00e9par\u00e9 est adapt\u00e9 \u00e0 l'attaque des syst\u00e8mes avec des processus serveur acceptant des connexions via des sockets r\u00e9seau, prenant en charge le protocole MPTCP (Multipath TCP). La prise en charge de MPTCP peut \u00eatre activ\u00e9e pour des sockets r\u00e9seau sp\u00e9cifiques, ce qui est fait par d\u00e9faut dans la biblioth\u00e8que standard du langage Go \u00e0 partir de la version Go 1.24 (f\u00e9vrier 2025). <\/p>\n
L'exploit pr\u00e9par\u00e9 peut \u00eatre utilis\u00e9 avec n'importe quelle application serveur en Go, y compris le serveur HTTP Caddy, si des paquets r\u00e9seau peuvent \u00eatre envoy\u00e9s au socket d'\u00e9coute cr\u00e9\u00e9 par ces applications. \u00c9tant donn\u00e9 que la vuln\u00e9rabilit\u00e9 se trouve directement dans la pile IPv4 et n'est pas sp\u00e9cifique \u00e0 MPTCP, il n'est pas exclu de cr\u00e9er des exploits fonctionnant sans lien avec MPTCP, bien que de tels exploits n'aient pas encore \u00e9t\u00e9 d\u00e9montr\u00e9s. Par exemple, l'exploitation de la vuln\u00e9rabilit\u00e9 peut \u00eatre possible lors du traitement des requ\u00eates de migration de sockets, accessible dans des configurations avec le param\u00e8tre net.ipv4.tcp_migrate_req=1 ou lors de l'utilisation de programmes eBPF avec l'option BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.<\/p>\n
La vuln\u00e9rabilit\u00e9 est caus\u00e9e par un \u00e9tat de concurrence qui se produit lors du traitement simultan\u00e9 de requ\u00eates SYN renvoy\u00e9es lors de l'\u00e9tablissement d'une connexion TCP. \u00c9tant donn\u00e9 que la fonction tcp_v4_syn_recv_sock() transmet des param\u00e8tres du sous-socket de la structure ireq->ireq_opt par r\u00e9f\u00e9rence plut\u00f4t que par copie, dans certaines circonstances, il arrive que la m\u00e9moire pour les structures inet_opt et ireq_opt contenant les param\u00e8tres du socket soit d\u00e9j\u00e0 lib\u00e9r\u00e9e, mais les options associ\u00e9es au socket continuent d'\u00eatre utilis\u00e9es (use-after-free). <\/p>\n
L'exploitation \u00e0 distance est r\u00e9alis\u00e9e en envoyant une s\u00e9rie de requ\u00eates r\u00e9seau synchronis\u00e9es dans le temps. L'exploit cr\u00e9\u00e9 est \u00e9galement applicable aux noyaux utilisant l'al\u00e9atoirement des adresses (KASLR), mais entrer dans la fen\u00eatre de l'\u00e9tat de concurrence prend beaucoup de temps et n\u00e9cessite de nombreuses tentatives. L'exploitation est facilit\u00e9e par le fait que ne pas entrer dans la fen\u00eatre de l'\u00e9tat de concurrence ne conduit qu'\u00e0 la r\u00e9initialisation de la session d'\u00e9tablissement de connexion (handshake) et non \u00e0 un crash du noyau, permettant ainsi de continuer ind\u00e9finiment les tentatives. Dans le prototype d'exploit cr\u00e9\u00e9, l'attaque a n\u00e9cessit\u00e9 environ une heure \u2014 48 minutes pour d\u00e9terminer la disposition de la m\u00e9moire et encore 5 minutes pour organiser l'ex\u00e9cution du code. <\/p>\n
Aucun contournement de la vuln\u00e9rabilit\u00e9 qui garantit un blocage n'est propos\u00e9 pour l'instant \u2014 la seule option fiable est de mettre \u00e0 jour le noyau. Le probl\u00e8me appara\u00eet \u00e0 partir du noyau Linux 4.4 et est corrig\u00e9 dans les versions 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3. Le statut de correction des vuln\u00e9rabilit\u00e9s dans les distributions peut \u00eatre \u00e9valu\u00e9 sur ces pages : Debian, Ubuntu, SUSE\/openSUSE, RHEL, Gentoo, Arch.
\nFedora. <\/p>\n
Parmi les recommandations pour contrer les m\u00e9thodes d'exploitation sp\u00e9cifiques qui ne bloquent pas la vuln\u00e9rabilit\u00e9 de mani\u00e8re g\u00e9n\u00e9rale, on peut citer la d\u00e9sactivation du support MPTCP et le param\u00e8tre sysctl du noyau net.ipv4.tcp_migrate_req d\u00e9fini sur 0 :<\/p>\n
sysctl -w net.mptcp.enabled=0
\n sysctl -w net.ipv4.tcp_migrate_req=0<\/p>\n
Pour v\u00e9rifier la pr\u00e9sence de processus utilisant des sockets avec
\nMPTCP, les commandes suivantes peuvent \u00eatre utilis\u00e9es :<\/p>\n
ip mptcp endpoint show
\n ip mptcp limits show<\/p>\n
Pour d\u00e9sactiver le support MPTCP dans les programmes en langage Go, utilisez le drapeau \u00ab multipathtcp=0 \u00bb, qui peut \u00eatre d\u00e9fini en configurant la variable d'environnement \u00ab GODEBUG=multipathtcp=0 \u00bb. Pour d\u00e9sactiver le support MPTCP au moment de la cr\u00e9ation, vous pouvez ajouter \u00ab godebug multipathtcp=0 \u00bb dans le fichier du module go.mod. Dans le code de l'application, l'utilisation de MPTCP peut \u00eatre d\u00e9sactiv\u00e9e via les fonctions net.Dialer.SetMultipathTCP et net.ListenConfig.SetMultipathTCP.<\/p>\n
En plus du probl\u00e8me examin\u00e9, Anthropic a \u00e9galement annonc\u00e9 une s\u00e9rie de vuln\u00e9rabilit\u00e9s exploitables localement dans le noyau Linux, OpenBSD et FreeBSD, permettant d'obtenir des droits root dans le syst\u00e8me et de sortir des conteneurs isol\u00e9s; des vuln\u00e9rabilit\u00e9s dans Chrome et Safari, conduisant \u00e0 l'ex\u00e9cution de code dans le syst\u00e8me lors de l'ouverture de pages web sp\u00e9cialement con\u00e7ues; une vuln\u00e9rabilit\u00e9 dans le noyau Windows provoquant un crash; une vuln\u00e9rabilit\u00e9 sur la plateforme Android permettant de contourner le verrouillage de l'\u00e9cran et d'acc\u00e9der \u00e0 des informations personnelles et des photos sans d\u00e9verrouillage de l'appareil (attaque d\u00e9montr\u00e9e sur le smartphone Google Pixel 9).<\/p>\n
La vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 confirm\u00e9e dans de nombreuses images officielles Docker, y compris les images couchbase, elasticsearch, flink, solr, storm, etc. <\/p>\n