Alerte de Mist : vulnérabilité critique d’escalade de privilèges sur Linux, désactiver trois modules pour une mitigation d’urgence

23pds, le directeur de la sécurité de l’information chez Mist, a divulgué le 8 mai qu’il existe sous Linux une vulnérabilité critique d’élévation de privilèges appelée Dirty Frag ; des détails complets et du code d’exploitation ont été publiés. N’importe quel utilisateur local avec de faibles privilèges peut, sans conditions spécifiques au système, obtenir directement les droits d’administrateur root sur les systèmes affectés. Les mesures d’atténuation d’urgence consistent à désactiver les trois modules esp4, esp6 et rxrpc.

Pourquoi Dirty Frag est-il si dangereux : faille logique, taux de réussite élevé, pas de correctif

Dirty Frag relève d’une vulnérabilité logique déterministe, et non d’une attaque instable reposant sur des conditions de concurrence, ce qui lui confère un taux de réussite très élevé et une capacité de reproduction stable. Les attaquants n’ont qu’à exécuter un petit programme pour obtenir immédiatement les privilèges root sur le système cible. Le processus entier ne provoque pas de crash du noyau, ce qui le rend extrêmement difficile à détecter par les contrôles de surveillance habituels.

La vulnérabilité a été soumise le 30 avril par des chercheurs en sécurité à l’équipe du noyau Linux, mais avant que les travaux de correction ne soient terminés, un « tiers sans lien » a divulgué en avance des informations détaillées et le code d’exploitation, obligeant la levée des restrictions de sécurité. La communauté de sécurité estime généralement que cela signifie que des acteurs malveillants pourraient déjà exploiter activement cette vulnérabilité.

D’un point de vue technique, Dirty Frag présente un mécanisme similaire à la vulnérabilité Copy Fail, qui cause aujourd’hui de nombreux dégâts dans le domaine des serveurs Linux : l’attaque consiste à insérer le descripteur de cache de pages dans une opération de copie sans copie. La faille racine « xfrm-ESP Page-Cache Write » a été introduite par un commit du noyau datant de 2017, cac2661c53f3 ; comme AppArmor sur Ubuntu a corrigé ce problème, le PoC relie une deuxième vulnérabilité « RxRPC Page-Cache Write » (commit 2dc334f1a63a) afin de garantir que l’attaque reste efficace également sur les systèmes Ubuntu.

Périmètre affecté : liste des distributions Linux principales confirmées

Distributions Linux (partiellement) confirmées comme affectées :

· Ubuntu 24 et Ubuntu 26 (y compris AppArmor, contournement via la deuxième vulnérabilité)

· Arch Linux (versions mises à jour également confirmées comme affectées)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (la version du noyau 7.0.3-1-cachyos a été confirmée comme déclenchable)

· WSL2 (Windows Subsystem for Linux) également confirmé comme affecté

Mesures d’atténuation d’urgence : commandes spécifiques pour désactiver les trois modules

Avant la publication officielle des correctifs, la méthode la plus efficace pour atténuer le risque est de désactiver les trois modules esp4, esp6 et rxrpc. Ces trois modules sont liés aux fonctionnalités réseau d’IPSec. Sauf si le serveur lui-même est un client ou un serveur IPSec, la désactivation n’affecte presque pas les activités normales.

Exécutez les commandes suivantes pour désactiver les modules : sh -c “printf ‘install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true”

Une fois l’exécution terminée, surveillez de près les annonces de sécurité de chaque distribution Linux, puis déployez immédiatement les mises à jour système dès la publication officielle des correctifs.

Questions fréquentes

Le correctif officiel pour la vulnérabilité Dirty Frag existe-t-il déjà ?

À ce jour, aucun correctif n’a encore été publié par les instances officielles et aucun commit de correction n’a été repéré dans le noyau Linux principal. Cela s’explique par le fait que les restrictions de sécurité ont été brisées avant même que le correctif soit prêt, ce qui a conduit à la publication des détails de la vulnérabilité alors que la correction n’était pas encore terminée. Les administrateurs système doivent suivre de près les annonces de sécurité des distributions Linux et déployer immédiatement dès la publication des correctifs.

Désactiver les modules esp4, esp6 et rxrpc va-t-il impacter le fonctionnement normal du serveur ?

Ces trois modules sont principalement liés aux protocoles IPSec. Sauf si le serveur lui-même est un client ou un serveur IPSec (c’est-à-dire utilisé pour des communications chiffrées au niveau réseau), la désactivation de ces modules n’affecte presque pas les activités générales comme les services Web, les bases de données, les nœuds de chiffrement, etc. C’est donc la solution d’atténuation d’urgence la plus sûre à l’heure actuelle, avec l’impact le plus faible.

Pourquoi cette vulnérabilité a-t-elle été divulguée alors qu’il n’y avait pas encore de correctif ?

Dans l’industrie, la pratique courante est la « divulgation responsable » : après avoir soumis une vulnérabilité aux fabricants, les chercheurs en sécurité attendent généralement que le correctif soit terminé avant de publier les détails. Cette vulnérabilité a été soumise le 30 avril, mais un « tiers sans lien » a divulgué en avance des informations détaillées, brisant ainsi la restriction. Les chercheurs en sécurité estiment que des attaquants malveillants pourraient déjà l’exploiter activement, ce qui explique le déclenchement final de la levée de la restriction.