Dirty Frag : une nouvelle vulnérabilité d'élévation de privilèges root découverte dans le noyau Linux
Dirty Frag : une nouvelle vulnérabilité d'élévation de privilèges root découverte dans le noyau Linux après Copy Fail. Microsoft affirme avoir déjà observé des pirates en train de l'expérimenter
Une nouvelle faille de sécurité critique a été découverte dans le noyau Linux : Dirty Frag. Cette vulnérabilité cible actuellement les systèmes Linux en permettant à des utilisateurs non autorisés d'obtenir les privilèges root. Elle exploite des erreurs de gestion de la mémoire au sein du noyau pour modifier des fichiers protégés, rendant les serveurs et les machines virtuelles vulnérables. Bien que des correctifs de production commencent à être déployés par des distributions comme Debian et Fedora, l'existence d'un code d'exploitation public accroît les risques de piratage. Elle intervient après la découverte de la faille de sécurité Copy Fail qui affecte le noyau.
Linux est confronté à une nouvelle faille critique appelée Dirty Frag, marquant la deuxième faille majeure découverte en l'espace de deux semaines. Cette faille de sécurité donne la possibilité à des utilisateurs disposant de faibles privilèges, y compris ceux utilisant des machines virtuelles (VM), d'obtenir un contrôle total (accès root) sur les serveurs. Cette situation est particulièrement risquée pour les environnements partagés par plusieurs utilisateurs.
Le risque est d'autant plus grand que le code permettant d'exploiter cette faille a été divulgué en ligne et que Microsoft a déjà observé des pirates en train de l'expérimenter. Des exploits publics démontrent qu'il est possible d'obtenir une élévation fiable des privilèges root depuis un compte local non privilégié.
Pour faire face à ce type de menace, Sasha Levin, ingénieur chez Nvidia et co-mainteneur du noyau stable de Linux, a proposé d'intégrer un kill switch. Cet outil permettrait aux administrateurs de désactiver instantanément des fonctionnalités spécifiques jugées vulnérables avant même qu'un correctif officiel ne soit déployé. Bien qu'il offre une protection immédiate contre l'exploitation de bogues, il ne remplace pas une mise à jour logicielle complète.
Dirty Frag : le mécanisme de corruption de la mémoire
Dirty Frag est une chaîne d'exploitation locale du noyau Linux permettant une élévation de privilèges jusqu'à root. Elle combine deux vulnérabilités : CVE-2026-43284 (écriture dans le cache de pages via xfrm-ESP) et CVE-2026-43500 (écriture via RxRPC). Elle appartient à la même famille que Dirty Pipe et Copy Fail. Son score CVSS provisoire est de 7.8, avec un vecteur d'attaque local, une faible complexité et aucune interaction utilisateur requise.
Le cache de pages Linux conserve en mémoire les copies des fichiers pour éviter des lectures répétées sur le disque. Certains chemins de réception réseau, comme IPsec (ESP) et RxRPC (AFS), supportent le déchiffrement dit "zero-copy" : les données chiffrées reçues sont déchiffrées dans une page de destination plutôt que dans un nouveau tampon. Dirty Frag survient lorsque cette page de destination n'est pas détenue de façon exclusive par le noyau.
Via des opérations splice(2) ou sendfile(2), un processus non privilégié peut amener le noyau à déchiffrer des données dans une page actuellement utilisée par le cache, comme des fichiers sensibles /etc/passwd. Les octets déchiffrés étant contrôlés par l'attaquant, l'écriture atterrit dans la copie partagée du cache. Le fichier sur disque reste intact, mais les lectures suivantes (par login, sudo, su…) récupèrent la version modifiée en mémoire.
La combinaison de failles pour une furtivité maximale
Dirty Frag combine deux failles distinctes : CVE-2026-43284, qui vise les processus esp4 et esp6, et CVE-2026-43500, qui cible rxrpc. Prises isolément, elles sont peu fiables, car elles peuvent être bloquées par des protections par défaut comme AppArmor ou par l'inactivité de certains modules réseau. Mais leur combinaison permet de contourner ces obstacles et de compromettre de manière fiable toutes les grandes distributions Linux testées.
Cette méthode de contournement rend l'attaque "déterministe", ce qui signifie qu'elle s'exécute de façon identique à chaque fois et sans provoquer de plantage, la rendant extrêmement furtive. Cette approche assure l'efficacité de l'attaque Dirty Frag lors de son exploitation par un acteur de la menace. Des exploits publics ont circulé en ligne avant que le correctif coordonné soit finalisé, réduisant drastiquement le temps de réaction des défenseurs.
Les deux chemins vulnérables se complètent pour couvrir les configurations durcies les plus courantes : le chemin ESP nécessite la création d'espaces de noms utilisateur non privilégiés (bloqué par Ubuntu via AppArmor, mais autorisé sur d'autres distributions) ; le chemin RxRPC nécessite le module rxrpc.ko, que la plupart des distributions ne chargent pas par défaut, mais Ubuntu si. Ensemble, ils couvrent pratiquement toutes les configurations.
Quelles sont les distributions concernées ?
Comme souligné précédemment, l'architecture de Dirty Frag couvre pratiquement toutes les configurations. Selon les experts en cybersécurité, vous êtes probablement concerné si vous utilisez un noyau Linux récent dérivé de la branche principale sur l'un des systèmes suivants :
- Ubuntu (versions LTS et actuelles) ;
- Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream ;
- Fedora ;
- openSUSE Tumbleweed ;
- la plupart des versions dérivées, y compris les variantes de CloudLinux.
Scénarios d'exploitation de Dirty Frag
Microsoft a publié un bulletin sur la Dirty Frag, affirmant qu'elle accroît les risques après la compromission. La firme de Redmond décrit la vulnérabilité comme une attaque en cours. Les acteurs malveillants peuvent exploiter Dirty Frag après avoir obtenu l'exécution de code local via plusieurs voies d'intrusion courantes :
- comptes SSH compromis ;
- accès à des shells Web sur des applications exposées à Internet ;
- évasion de conteneurs vers l'environnement hôte ;
- abus de comptes de service à faibles privilèges ;
- activités post-exploitation à la suite d'une attaque par hameçonnage ou d'une compromission de l'accès à distance.
Une fois l'accès local établi, une exploitation réussie peut permettre aux attaquants d'élever leurs privilèges au niveau root et d'obtenir un contrôle étendu sur l'hôte Linux affecté. L'entreprise ajoute que Microsoft Defender détecte actuellement une activité limitée en milieu réel, caractérisée par une élévation de privilèges impliquant la commande « su », ce qui pourrait indiquer l'utilisation de techniques associées à Dirty Frag ou Copy Fail.
Recommandations d'atténuation
Le 8 mai 2026, la Linux Kernel Organization a publié des correctifs, dont les liens figurent dans la National Vulnerability Database (NVD), afin de corriger la vulnérabilité CVE-2026-43284. Les utilisateurs et les organisations sont invités à appliquer ces correctifs dès que possible. Au 8 mai 2026, aucun correctif n'est disponible pour la vulnérabilité CVE-2026-43500. Les organisations doivent évaluer immédiatement les mesures d'atténuation provisoires.
Les mesures recommandées sont les suivantes :
- désactiver les modules du noyau rxrpc inutilisés lorsque cela est possible d'un point de vue opérationnel ;
- évaluer si les fonctionnalités esp4, esp6 et les fonctionnalités xfrm/IPsec associées peuvent être temporairement désactivées en toute sécurité ;
- limiter les accès shell locaux non nécessaires ;
- renforcer la sécurité des charges de travail en conteneurs ;
- renforcer la surveillance des activités anormales d'escalade de privilèges ;
- donner la priorité au déploiement des correctifs du noyau dès la publication des avis des éditeurs.
Ces mesures d'atténuation doivent être soigneusement évaluées avant leur mise en œuvre, en particulier dans les environnements qui s'appuient sur des VPN IPsec ou sur la fonctions RxRPC. L'exemple suivant empêche le chargement des modules vulnérables et décharge les modules actifs lorsque cela est possible :
Vérification de l'intégrité après les mesures correctives
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Les mesures correctives ne suffisent pas toujours à annuler les modifications déjà introduites à la suite de tentatives d'exploitation réussies. Si l'exploitation a eu lieu avant la mise en œuvre des mesures correctives, des modifications malveillantes peuvent persister en mémoire ou dans le contenu des fichiers mis en cache, même après la désactivation des modules vulnérables. Il faut déterminer si la purge du cache est appropriée dans leur environnement.
Selon le bulletin de sécurité publié par Microsoft, la purge du cache peut entraîner une augmentation temporaire des opérations d'E/S sur le disque et avoir un impact sur les performances en production ; elle doit donc être soigneusement évaluée avant tout déploiement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part echo 3 | sudo tee /proc/sys/vm/drop_caches
Comment détecter une infection par Dirty Frag ?
Il n'existe pas encore de méthode de détection post-exploitation fiable et largement reconnue. Les fichiers sur disque sont intacts et l'attaque ne laisse pas de signature syscall aussi distinctive que Dirty Pipe. Des signaux à surveiller incluent : le chargement inattendu des modules esp4, esp6 ou rxrpc sur des hôtes qui n'ont aucune raison d'utiliser IPsec ou AFS ; des créations inhabituelles d'espaces de noms réseau par des utilisateurs non privilégiés...
Dirty Pipe, Copy Fail et Dirty Frag partagent le même problème fondamental : des chemins rapides du noyau qui écrivent dans des pages dont ils supposent la propriété exclusive sans la vérifier. Chaque fonctionnalité zero-copy ou transformation ajoutée pour des raisons de performance crée une nouvelle occasion d'écrire dans une page inattendue. Le cache de pages est une cible de choix, car il est partagé par conception et fait confiance par tous ses lecteurs.
La vulnérabilité Dirty Drag est particulièrement redoutable par sa furtivité et sa fiabilité, ne provoquant aucun plantage lors de son exécution sur diverses plateformes. Les experts recommandent une mise à jour immédiate des systèmes pour contrer cette attaque qui succède de peu à une autre faille similaire.
La priorité est d'installer la mise à jour du noyau fournie par le fournisseur et de redémarrer le système dès que possible. Si le correctif n'est pas encore disponible, appliquer le blocage de modules (après confirmation de l'absence d'usage IPsec ou RxRPC). Il convient également d'auditer les accès locaux sur les hôtes partagés, serveurs CI/CD et systèmes multilocataires, et de lancer les requêtes de détection sur la fenêtre d'exposition.
Proposition d'ajout d'un kill switch au noyau Linux
À la suite de la divulgation récente de failles de sécurité critiques, telles que Copy Fail et Dirty Frag, les développeurs du noyau Linux examinent actuellement une proposition visant à intégrer un mécanisme d'arrêt d'urgence, ou kill switch. Ce correctif a été soumis par Sasha Levin, ingénieur chez Nvidia et co-mainteneur du noyau stable de Linux. Ce mécanisme a été pensé comme une nouvelle couche de sécurité face aux vulnérabilités jugées graves.
Ce mécanisme d'arrêt d'urgence repose sur un principe simple : offrir aux administrateurs disposant des droits requis la possibilité de neutraliser temporairement, via l'interface securityfs, une fonction du noyau jugée vulnérable. Lorsqu'un chemin de code dangereux est ciblé par l'arrêt d'urgence, la fonction cesse de s'exécuter normalement et renvoie simplement une erreur, bloquant ainsi l'exploitation de la vulnérabilité par les acteurs de la menace.
Le noyau Linux est constitué de milliers de petites fonctions, chacune chargée d'une tâche spécifique, comme le traitement d'un paquet réseau ou la communication avec un périphérique USB. Lorsqu'une faille apparaît dans l'une de ces fonctions, la solution consiste à corriger le code et à publier un nouveau noyau. Le kill switch implique une approche plus radicale, où l'administrateur fournit au noyau Linux un nom de fonction et une valeur de retour.
À partir de ce moment, la fonction continue d'être appelée par ce qui l'appelait auparavant, mais elle se contente de renvoyer cette valeur et de se fermer. Le code qu'elle contient ne s'exécute jamais. Selon la documentation fournie par Sasha Levin, ce mécanisme cible principalement des chemins de code sur lesquels la plupart des systèmes ne s'appuient pas quotidiennement, comme les fonctions AF_ALG, ksmbd, nf_tables, vsock et ax25.
Risques et limites de ce mécanisme d'arrêt d'urgence
L'utilisation de cette fonctionnalité n'est pas sans danger et ne comporte aucune vérification de sécurité automatique pour déterminer si une fonction peut être bloquée sereinement. En cas de mauvaise manipulation, la désactivation d'une fonction inadéquate pourrait gravement perturber le comportement du système ou créer de nouvelles pannes. Sasha Levin note que ce mécanisme ne constitue en aucun cas un correctif définitif ou du "live patching".
Ce mécanisme ne remplace pas non plus le code défectueux et requiert toujours une mise à jour complète du noyau pour résoudre la vulnérabilité de manière permanente. Pour le moment, cette rustine logicielle est toujours en phase d'évaluation et n'a pas encore été acceptée dans le noyau Linux. Son activation corrompt également le noyau, ce qui est sa façon de signaler que le code en cours d'exécution n'est plus le code Linux « en amont » pur.
Un drapeau (H, bit 20) est activé dès qu'un kill switch est actif, et il persiste même après sa désactivation, jusqu'au prochain redémarrage. Tout plantage survenant par la suite comporte un H dans son en-tête, ce qui sert de signal à l'administrateur, indiquant que l'image a été modifiée. Le correctif consacre également une section entière intitulée « Choisir la bonne cible », avertissant les opérateurs de ne pas sélectionner la mauvaise fonction.
Les réactions à cet outil sont partagées. Certains utilisateurs y voient un outil potentiellement utile pour pallier des dysfonctionnements matériels, comme le blocage d'un pilote. Mais d'autres expriment de sérieuses réserves, craignant que cet outil ne soit abusé par des acteurs malveillants, n'augmente la surface d'attaque globale, ou ne soit mal utilisé par les administrateurs au risque d'endommager involontairement leurs propres systèmes.
Un utilisateur a qualifié cela de « fonctionnalité de sécurité qui pourrait s'avérer pire que la faille elle-même ». « Pour être honnête, cette idée me semble augmenter la surface d'attaque et en faire une cible idéale pour un déni de service, mais je ne suis pas un expert en sécurité », a écrit un utilisateur sceptique.
Sources : Microsoft, Red Hat
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
Partager