Une faille critique dans le noyau Linux permet de faire planter un serveur via TCP

Une faille critique dans le noyau Linux permet de faire planter un serveur via TCP Une poignée de mains et patatras Illustration : Flock Vincent Hermann Le 04 novembre à 11h07 Une nouvelle faille critique a été découverte dans le noyau Linux. Avec un score CVSS de 9,8 sur 10, sa dangerosité frôle la note maximale, permettant une exploitation à distance. Selon la distribution utilisée, le correctif peut être disponible ou non.

Une erreur ? Les distributions Linux reçoivent peu à peu de nouveaux noyaux contenant un correctif pour la faille estampillée CVE-2026-98432. La situation est très variable selon les systèmes, Red Hat ayant publié de nouveaux noyaux par exemple, alors que chez Canonical, les correctifs pour Ubuntu restent pour l’instant cantonnés au dépôt de test, sans date de publication générale.

D’autres encore ont réglé le problème au cours des deux dernières semaines. La faille est connue publiquement depuis le 15 octobre. Elle est présente dans le noyau Linux depuis sa version 4.4, qui remonte à une dizaine d’années.

Deux cœurs pour une même mémoire Pour comprendre comment fonctionne la faille, rappelons d’abord quelques bases. Lorsqu’un serveur accepte une connexion TCP, il échange d’abord trois messages avec le client : le client demande l’ouverture (SYN), le serveur accepte (SYN-ACK), puis le client confirme (ACK). Pendant cet échange, le serveur garde en mémoire certaines informations envoyées par le client, les options IP.

Tant que l’échange n’est pas terminé, le noyau Linux range ces informations dans une fiche provisoire (demande en attente). À la réception du dernier message (ACK), il crée la fiche définitive de la connexion. Au lieu de recopier les options IP dans cette nouvelle fiche, il se contente d’y noter leur emplacement en mémoire.

Les deux fiches désignent alors la même zone mémoire, et la fiche provisoire peut encore être utilisée. On peut voir venir le problème. Il survient quand deux cœurs du processeur travaillent en même temps, soit un scénario très commun sur n’importe quel serveur aujourd’hui.

Si le client renvoie sa demande de connexion, un cœur peut être en train de lire ces informations pour y répondre, tandis que l’autre vient de les effacer en fermant la connexion. Le premier lit alors une mémoire qui ne lui appartient plus et qui peut tout à fait avoir été réaffectée à un autre processus. Ce mécanisme peut être exploité, la faille étant donc de type use-after-free (utilisation de mémoire après libération).

S’il veut déclencher ce conflit et donc exploiter la faille, le pirate n’a pas besoin de compte. Il lui « suffit » d’envoyer des demandes de connexions contenant certaines options IPv4 peu utilisées (comme Record Route ou Timestamp) vers n’importe quel port TCP ouvert. Les connexions IPv6 ne sont pas concernées.

De fait, le correctif à appliquer est simple : il impose au noyau d’attendre que plus personne ne lise les informations en mémoire avant de les effacer. La gravité de la faille ne fait pas consensus Officiellement, le score CVSS est bien de 9,8. Et pour cause : l’exploitation se fait avec un simple accès réseau, ne semble pas complexe, ne réclame aucun privilège particulier ni interaction côté victime, et l’impact potentiel sur la confidentialité, l’intégrité et la disponibilité est élevé.

La faille peut en effet servir aussi bien à déclencher un plantage qu’à voler des informations. Red Hat, dans sa fiche sur la vulnérabilité, considérait initialement cette faille comme « modérée », avec un score de 5,9. L’éditeur s’est pourtant ravisé, s’alignant sur la note de 9,8 et la considérant donc comme critique.

Mais tous ne l’ont pas fait. Chez AWS (pour sa distribution Amazon Linux) par exemple, on considère que la faille a un score de 8,1, ce qui la place dans la catégorie « importante ». Amazon considère que ce « problème entraîne principalement un plantage du système menant à un déni de service (DoS) ou une possible corruption de la mémoire ».

Canonical, dans son bulletin du 2 novembre sur la faille, reprenait directement la note de 9,8. Qui est à l’abri ? Comme indiqué, la situation dépend largement du système utilisé.

Côté Ubuntu par exemple, si vous utilisez une mouture 26.10 à jour, aucun problème : le correctif est présent dans le noyau 7.3.0 - 10.10. En revanche, pour toutes les autres versions, il faut attendre ou installer un correctif pas tout à fait finalisé. Ubuntu 26.04, 24.04 et 22.04 peuvent ainsi puiser dans le dépôt -proposed pour des révisions des noyaux (respectivement les branches 7.0, 6.8 et 5.15).

Pour les versions plus anciennes, le correctif est en préparation. Sur Amazon Linux, le correctif a été distribué entre les 24 et 30 octobre, selon les versions. Pour Red Hat, on l’a vu, les correctifs sont également disponibles.

D’autres distributions ont réagi plus tôt, notamment Debian, SUSE ou encore Oracle Linux, qui ont toutes reçu des correctifs durant la seconde moitié d’octobre. La situation suffit en tout cas à justifier une mise à jour rapide. On parle tout de même d’un défaut accessible sans authentification sur tout port TCP IPv4 en écoute, présent depuis dix ans, avec au minimum un risque de déni de service et de fuite mémoire.

L’exécution de code à distance n’a été en revanche démontrée que par un seul acteur : Anthropic. Dans un billet du 27 octobre, l’entreprise a en effet indiqué qu’elle avait utilisé un modèle de recherche interne pour créer une chaine d’exploitation aboutissant aux droits root, dans des conditions particulières. Il ne semble pas pour l’instant que la vulnérabilité soit réellement exploitée, mais certains chercheurs évoquent désormais une activité a priori malveillante pour chercher les serveurs exposés.

Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant. Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous cquest Il y a 28 minutes Voir les réponses Message 1 Aller au commentaire enfant Signaler Bloquer cet utilisateur Les connexions IPv6 ne sont pas concernées.C'est bon l'IPv6, mangez-en !!!! koocotte Premium À l'instant En réponse à Message 1.1 Signaler Bloquer cet utilisateur La description de la CVE dit quand même que IPv6 aura une correction, mais je n'ai pas trop le niveau pour comprendre quel est le risque, manifestement c'est que dans le cas où l'on utilise Calipso, qui d'après https://www.paul-moore.com/blog/d/2016/12/calipso_intro.html sert justement à faire de la sécurité:IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO.

This will be addressed in a separate patch. Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ? Non Oui