<![CDATA[Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande »]]>

Dirty Frag, c’est le nom de la nouvelle faille de sécurité critique qui affecte les machines Linux. Cette faille zero-day est similaire à Copy Fail puisqu’elle permet une élévation de privilèges en tant que root. Voici l’essentiel à savoir sur cette menace potentielle.

Dirty Frag : ça explose avant la date prévue

La vulnérabilité Dirty Frag a été découverte par le chercheur Hyunwoo Kim, qui avait initialement planifié une divulgation coordonnée pour le 12 mai 2026. Cependant, quelqu’un est parvenu à détecter des informations relatives à cette vulnérabilité, et donc tout a été publié en avance ce jeudi 7 mai 2026.

Hyunwoo Kim a pris la décision de publier tous les détails, notamment pour alerter la communauté : “Parce que l’embargo a été rompu, aucun correctif ni CVE n’existe pour ces vulnérabilités. Après consultation avec les mainteneurs de linux-distros@vs.openwall.org, et à la demande des mainteneurs, je publie publiquement ce document Dirty Frag.”.

Désormais, voici ce qui est disponible :

  • Un writeup technique complet pour présenter cette vulnérabilité dans les moindres détails,
  • Un code d’exploitation “universel” puisqu’il fonctionne sur de nombreuses distributions Linux.

Cela rappelle la situation avec CopyFail. Sauf que là, c’est une autre vulnérabilité : Dirty Frag. Pour le moment, il n’y a pas de référence CVE, et surtout, pas de patchs (même si cela commence à arriver).

Qu’est-ce que la vulnérabilité Dirty Frag ?

Il y a des similitudes entre Dirty Frag et deux autres failles de sécurité : CopyFail (2026) et Dirty Pipe (2022). Ce nouvel exploit repose en réalité sur deux vulnérabilités, l’une dans xfrm-ESP et l’autre dans RxRPC. À chaque fois, il s’agit d’un problème de sécurité lié à l’écriture de données dans le page cache (comme pour CopyFail). D’ailleurs, le chercheur explique que la faille CopyFail l’a motivé à effectuer ce travail de recherche.

La vulnérabilité est déclenchée lorsque le noyau Linux effectue des opérations cryptographiques “sur place”. Cette faille logique permet d’écraser directement des données en RAM. Ainsi, un utilisateur sans privilèges peut modifier à la volée le contenu de fichiers critiques du système d’exploitation, normalement restreints à une simple lecture, tels que /usr/bin/su ou /etc/passwd.

Si le chercheur a chaîné deux vulnérabilités, ce n’est pas un hasard. C’était nécessaire pour créer un exploit universel, c’est-à-dire un exploit capable de contourner les défenses spécifiques de certains systèmes (AppArmor, par exemple).

  • Le vecteur xfrm-ESP : cette vulnérabilité offre la capacité d’écriture arbitraire de 4 octets (similaire à ce que permettait Copy Fail). Bien qu’elle soit présente sur la plupart des distributions Linux, elle exige une condition stricte : l’attaquant doit posséder les privilèges nécessaires pour créer un namespace. Le problème pour l’attaquant, c’est que sur des environnements comme Ubuntu, la création de namespaces par des utilisateurs non privilégiés est parfois bloquée par les politiques de sécurité d’AppArmor, rendant l’attaque xfrm-ESP impossible.
  • Le vecteur RxRPC : c’est ici que la seconde faille entre en jeu. Contrairement à xfrm-ESP, l’attaque via RxRPC ne nécessite aucun privilège lié à la création de namespaces. Cependant, elle a aussi un défaut : le module noyau rxrpc.ko n’est pas inclus dans la grande majorité des distributions. Enfin, il y a tout de même une exception avec Ubuntu, puisque ce dernier charge ce module par défaut !

En réunissant ces deux techniques, l’exploit s’adapte à son environnement. Si la distribution autorise les namespaces mais ne possède pas RxRPC, xfrm-ESP fait le travail. Si la distribution bloque les namespaces avec AppArmor mais charge RxRPC par défaut (comme Ubuntu), la seconde méthode prend le relais. Vous l’aurez compris : l’un ou l’autre peut suffire, mais l’exploit Dirty Frag combine les deux.

D’après les informations publiées par le chercheur, Dirty Frag permet d’obtenir un accès root sur la majorité des distributions Linux. Vous voulez des noms ? Je vais vous en donner : Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, Fedora 44, AlmaLinux 44 ou encore openSUSE Tumbleweed. En effectuant quelques recherches sur le Web, on constate rapidement que Debian est aussi affecté.

Le code d’exploitation PoC est disponible sur GitHub et il prend la forme d’un fichier codé en C (exp.c).

Comment se protéger contre Dirty Frag ?

Désormais, tout le monde va attendre une chose : les patchs officiels pour l’ensemble des distributions Linux affectées par Dirty Frag. Étant donné que la vulnérabilité fonctionne sur une machine équipée d’un noyau à jour (7.0.4), un correctif est attendu dans la version 7.0.5 du noyau Linux. Mais cela ne suffira pas, car comme pour CopyFail, il va falloir couvrir aussi les précédentes versions.

En attendant, que faire ?

Le chercheur Kim propose une solution temporaire. “Étant donné que le calendrier de divulgation responsable et l’embargo n’ont pas été respectés, aucun correctif n’est disponible pour aucune distribution. Utilisez la commande suivante pour supprimer les modules concernés par ces vulnérabilités.”, explique-t-il.

Voici la commande en question :

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"

En réalité, les modules ne sont pas supprimés. Cette commande permet de les désactiver, ou de les bloquer si vous préférez, lorsque l’exploit Dirty Frag va tenter d’en faire usage. Cette commande crée le fichier /etc/modprobe.d/dirtyfrag.conf contenant les trois lignes suivantes :

  • install esp4 /bin/false
  • install esp6 /bin/false
  • install rxrpc /bin/false

Attention tout de même, la désactivation de ces modules peut avoir des effets indésirables en fonction des services exécutés sur votre serveur. À ce sujet, j’avoue ne pas trop avoir d’informations (si vous avez des retours, je suis preneur). J’ai vu un post qui parlait d’un impact potentiel sur IPSEC.

Enfin, sachez que des travaux sont en cours pour patcher cette vulnérabilité au plus vite. Par exemple, un article publié sur le blog d’AlmaLinux indique que les correctifs sont prêts à être testés.

– Source : https://www.it-connect.fr/dirty-frag-cette-faille-zero-day-donne-les-droits-root-sur-linux/

]]>https://planete-warez.net/topic/8647/dirty-frag-faille-linux-critique-qui-offre-les-droits-root-en-une-seule-commandeRSS for NodeSun, 10 May 2026 12:55:13 GMTSat, 09 May 2026 20:04:14 GMT60<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sun, 10 May 2026 05:49:44 GMT]]>bonjour, je vais déjà rechercher des infos sur ce truc, si je bricole le système, j’y vais toujours avec prudences, on a vite fait de tout casser sur Linux. Puis, j’ai des sauvegardes et sauvegardes sur la sauvegarde…

]]>https://planete-warez.net/post/120603https://planete-warez.net/post/120603Sun, 10 May 2026 05:49:44 GMT<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sat, 09 May 2026 21:23:45 GMT]]>

@Violence a dit:

Le module n’a pas besoin d’être chargé au démarrage pour être exploitable, il suffit qu’il soit chargeable

Ah oui vu comme ça, j’étais bien vulnérable alors… undefined

]]>https://planete-warez.net/post/120567https://planete-warez.net/post/120567Sat, 09 May 2026 21:23:45 GMT<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sat, 09 May 2026 21:15:32 GMT]]>Est-ce que c’est le genre de manip d’un acteur étatique qui voudrait pousser du code malicieux rapidement à travers les pipelines de MaJ pour éviter que son malware soit attappé comme la vulnérabilité dans xz il y a un an ou deux ?

]]>https://planete-warez.net/post/120565https://planete-warez.net/post/120565Sat, 09 May 2026 21:15:32 GMT<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sat, 09 May 2026 21:12:47 GMT]]>@kemkem

Les modules n’étaient pas utilisé pour ma part, mais j’ai appliqué le fix par sécurité pour éviter une exploitation en attendant le kernel fix sur Ubuntu
Le module n’a pas besoin d’être chargé au démarrage pour être exploitable, il suffit qu’il soit chargeable d’où la mitigation manuelle en attendant

]]>https://planete-warez.net/post/120563https://planete-warez.net/post/120563Sat, 09 May 2026 21:12:47 GMT<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sat, 09 May 2026 21:07:20 GMT]]>Fixé sur les debian (security), mais de toute façon je n’étais pas concerné par les 2 failles de l’exploit. C’est la raison de mon minimalisme : réduire la surface d’attaque.

]]>https://planete-warez.net/post/120561https://planete-warez.net/post/120561Sat, 09 May 2026 21:07:20 GMT<![CDATA[Reply to Dirty Frag : Faille Linux critique qui offre les droits root « en une seule commande » on Sat, 09 May 2026 20:16:31 GMT]]>09/05/2026

Actuellement patché chez Alma Linux mais pas ailleurs encore (à ma connaissance)

Attention, la mitigation casse deux choses :

  • IPsec (modules esp4/esp6) — utilisé par les VPN type StrongSwan, certains tunnels, et parfois le réseau Kubernetes/conteneurs
  • RxRPC — utilisé par AFS (très rare en pratique)

Sur une Ubuntu 24.04.4

Avant d’appliquer, vérifier rapidement si vous utilisez IPsec :

Vérifier les modules actuellement chargés :

lsmod | grep -E 'esp4|esp6|rxrpc|xfrm'

Vérifier si tunnels IPsec actifs :

sudo ip xfrm policy 2>/dev/null | head
sudo ip xfrm state 2>/dev/null | head

Vérifier si StrongSwan installé :

systemctl status strongswan-starter ipsec 2>/dev/null

Si pas d’IPsec, pas d’AFS, pas de Kubernetes avec CNI à base d’IPsec → appliquer la mitigation maintenant, c’est sans risque

VPN IPsec en prod → ne couper pas aveuglément, planifie une fenêtre ou attender le patch (surveiller apt list --upgradable et le tracker https://ubuntu.com/security/CVE-2026-43284)

Serveur multi-tenants ou exécutant du code tiers → appliquer tout de suite, le risque d’évasion de conteneur fait pencher fortement la balance

Mitigation manuelle :

Étape 1 : bloquer les modules au prochain boot et régénérer l’initramfs

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all

Étape 2 : décharger les modules maintenant

sudo rmmod esp4 esp6 rxrpc 2>/dev/null

Étape 3 : vérifier
grep -qE '^(esp4|esp6|rxrpc) ’ /proc/modules && echo “Modules ENCORE chargés - reboot nécessaire” || echo “OK, modules déchargés”

Si l’étape 3 dit qu’il faut rebooter, c’est qu’un process utilise encore IPsec , dans ce cas un sudo reboot est nécessaire pour que la mitigation soit effective.

– Quand le kernel sera patché :

Surveiller les mises à jour

sudo apt update && apt list --upgradable | grep linux-image

Une fois le kernel mis à jour ET rebooté, retirer la mitigation

sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
]]>https://planete-warez.net/post/120555https://planete-warez.net/post/120555Sat, 09 May 2026 20:16:31 GMT