Dirty Frag : vulnérabilité LPE Linux générique (élévation locale de privilèges)

 (openwall.com)
2 points par GN⁺ 2 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Dirty Frag est une vulnérabilité générique d’élévation locale de privilèges permettant d’obtenir les droits root sur les principales distributions Linux ; le calendrier de divulgation responsable et l’embargo ayant été rompus, aucun correctif ni CVE n’est encore disponible
  • Extension de la même classe de bugs que Dirty Pipe et Copy Fail, il s’agit d’un bug logique déterministe qui ne nécessite pas de race condition et présente un taux de réussite très élevé
  • La durée de vie effective de la vulnérabilité est d’environ 9 ans ; elle a été testée sur les principales distributions comme Ubuntu, RHEL, Fedora et openSUSE
  • Même les systèmes ayant appliqué les mesures d’atténuation existantes pour Copy Fail (liste noire algif_aead) restent vulnérables à Dirty Frag
  • En mesure d’atténuation temporaire, il est recommandé de supprimer les modules esp4, esp6 et rxrpc impliqués dans la vulnérabilité jusqu’à la publication de correctifs par les distributions

Aperçu

  • Classe de bugs qui corrompt le membre frag de la structure sk_buff, extension de la même classe de bugs que Dirty Pipe et Copy Fail
  • En chaînant les vulnérabilités xfrm-ESP Page-Cache Write et RxRPC Page-Cache Write, il est possible d’obtenir les droits root sur les principales distributions Linux
  • Bug logique déterministe qui ne dépend pas d’une fenêtre de timing, sans nécessité de race condition
  • Même en cas d’échec de l’exploit, aucun kernel panic ne se produit, et le taux de réussite est très élevé

Pourquoi chaîner les deux vulnérabilités

  • xfrm-ESP Page-Cache Write fournit un puissant primitive de STORE arbitraire de 4 octets similaire à Copy Fail et est inclus dans la plupart des distributions, mais il nécessite l’autorisation de créer des espaces de noms
  • Sur Ubuntu, la politique AppArmor peut bloquer la création d’espaces de noms utilisateur non privilégiés ; dans cet environnement, il est donc impossible de déclencher xfrm-ESP Page-Cache Write
  • RxRPC Page-Cache Write ne nécessite pas l’autorisation de créer des espaces de noms, mais le module rxrpc.ko lui-même n’est pas inclus dans la plupart des distributions
    • Toutefois, sur Ubuntu, le module rxrpc.ko est chargé par défaut
  • En chaînant les deux vulnérabilités, leurs angles morts se compensent mutuellement, ce qui permet d’obtenir les droits root sur toutes les grandes distributions

Relation avec Copy Fail

  • Copy Fail est la motivation qui a lancé cette recherche
  • xfrm-ESP Page-Cache Write partage le même sink que Copy Fail, mais peut être déclenché indépendamment de la disponibilité du module algif_aead
  • Même les systèmes ayant appliqué la mesure d’atténuation publiée pour Copy Fail (liste noire algif_aead) restent vulnérables à Dirty Frag

Portée de l’impact

  • xfrm-ESP Page-Cache Write : du commit cac2661c53f3 (2017-01-17) jusqu’à l’upstream actuel
  • RxRPC Page-Cache Write : du commit 2dc334f1a63a (2023-06) jusqu’à l’upstream actuel
  • La durée de vie effective de la vulnérabilité est d’environ 9 ans
  • Versions de distributions testées :
    • Ubuntu 24.04.4 : 6.17.0-23-generic
    • RHEL 10.1 : 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed : 7.0.2-1-default
    • CentOS Stream 10 : 6.12.0-224.el10.x86_64
    • AlmaLinux 10 : 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44 : 6.19.14-300.fc44.x86_64

Mesures d’atténuation

  • Le calendrier de divulgation responsable et l’embargo ayant été rompus, aucune distribution ne dispose d’un correctif à ce stade
  • Comme mesure d’atténuation temporaire, une commande est fournie pour supprimer les modules où la vulnérabilité se manifeste : 
    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"
    • Ajoute les modules esp4, esp6 et rxrpc à la liste noire dans /etc/modprobe.d/dirtyfrag.conf, puis les décharge
  • Il faudra appliquer les mises à jour une fois que chaque distribution aura rétroporté les correctifs

Historique de la divulgation

  • Le document sur Dirty Frag a été publié après concertation avec les mainteneurs de linux-distros@vs.openwall.org, à leur demande
  • L’embargo a été rompu pour des raisons externes, et il n’existe actuellement ni correctif ni CVE
  • Le PoC a été publié en concertation avec linux-distros dans le but de fournir des informations exactes ; son usage sur des systèmes non autorisés est interdit

À lire aussi

2 commentaires

 
GN⁺ 1 시간 전
Réactions sur Hacker News

  • La cause racine et la méthode d’exploitation sont très proches de Copy Fail.
    À mes yeux, c’est un bon exemple de ce qu’on perd facilement quand on délègue beaucoup de travail à un LLM, à savoir l’exploration. J’ai l’impression que faire de la recherche sur les vulnérabilités avec l’IA bloque pas mal la créativité. Quand on pose une question et qu’on obtient immédiatement une réponse, on ne voit plus ce qu’il y a autour. C’est comme un génie qui ne donne exactement que ce qu’on lui demande, sans rien de plus.
    Le chercheur qui a trouvé Copy Fail s’est beaucoup appuyé sur l’IA après avoir remarqué quelque chose de suspect, mais s’il avait fouillé davantage le code lui-même, il aurait sans doute eu plus de chances de tomber sur ce bug jumeau. En même temps, avec des prompts un peu moins directifs, les LLM récents auraient probablement trouvé ces bugs aussi. C’est un cas assez inhabituel de synergie négative : ils ont travaillé ensemble, mais le résultat a été moins bon

    • Sauf erreur de lecture de ma part, ce n’est pas juste similaire, c’est la même cause racine. C’est un problème lié aux 32 bits de poids fort de l’Extended ESN d’IPsec == au module/mode de chiffrement authencesn.
      Dans copy.fail, c’est autre chose qui a été corrigé, et les gens ont trop vite rejeté la faute sur AF_ALG.
      [Édit : oui, c’est bien le même problème authencesn. Dans le code https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb..., authencesn n’apparaît que dans les commentaires, mais c’est quand même le même problème.]
      [Édit 2 : le problème RxRPC est distinct ; ici je parle du côté ESP]
    • On peut aussi faire un prompt de suivi du type « trouve-moi des bugs du même genre ». Une fois qu’un cas concret a été documenté, trouver des bugs similaires n’est pas si difficile.
      Je comprends l’argument sur la créativité. Comme n’importe quel outil, l’IA peut rétrécir le champ de vision. Il est difficile de s’en servir seulement comme assistant sans lui céder entièrement le workflow
    • Je ne comprends pas. Ce sont précisément les LLM qui ont découvert ces bugs. Pourtant on a l’impression qu’on présente cette découverte comme un signal que les LLM sont mauvais pour trouver des vulnérabilités
    • Je me demande s’il y a de vrais éléments derrière ce propos, ou si c’est juste une improvisation
    • Il est très difficile de tirer comme leçon d’une vulnérabilité racine similaire, mais pas exactement identique, trouvée par l’IA, que l’IA n’explore pas bien.
      Hormis le cas où les deux vulnérabilités auraient été publiées ensemble, je me demande dans quel scénario contrefactuel on dirait qu’elle a « suffisamment bien exploré »

  • « Il n’existe ni correctif ni CVE pour ces vulnérabilités, car l’embargo a été rompu »
    Lien : https://github.com/V4bel/dirtyfrag
    Analyse détaillée : https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    Le point important est celui-ci : « Copy Fail a motivé le lancement de cette recherche. En particulier, l’écriture dans le page cache xfrm-ESP de la chaîne de vulnérabilité Dirty Frag partage le même sink que Copy Fail. Mais elle se déclenche indépendamment de la disponibilité du module algif_aead. Autrement dit, même sur les systèmes où la mesure d’atténuation publique de Copy Fail — la mise en liste noire d’algif_aead — est appliquée, Linux reste vulnérable à Dirty Frag »
    L’atténuation proposée est la suivante, même si je ne l’ai ni testée ni vérifiée moi-même : « Comme le calendrier de divulgation responsable et l’embargo ont été rompus, aucune distribution n’a de correctif. Supprimez les modules qui déclenchent la vulnérabilité avec la commande ci-dessous »
    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"
    Dans la discussion sur cette atténuation, il est dit qu’un redémarrage peut être nécessaire, ou que sur une machine déjà exploitée il faut lancer ensuite : sudo echo 3 > /prox/sys/vm/drop_caches

    • Dans sudo echo 3 > /prox/sys/vm/drop_caches, sudo n’a aucun effet. sudo n’exécute que echo, pas l’écriture réelle.
      Et si la machine a déjà été exploitée, c’est de toute façon trop tard. N’importe quoi sur le disque a pu être corrompu, donc il faut reconstruire l’image complète du disque
    • On ne peut pas utiliser sudo echo avec une redirection comme ça depuis un shell non sudo.
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      ou
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      Et j’ai aussi corrigé la faute de frappe sur /proc
    • À noter que echo 1 > ... suffit aussi comme atténuation. Pas besoin de tout vider : il suffit de purger le page cache avec 1.
      Testé localement sur Ubuntu 26.04 : j’ai exécuté l’exploit, obtenu root, configuré l’atténuation, puis relancé su sans argument et je suis redevenu root immédiatement sans mot de passe. Après purge du page cache, su a de nouveau demandé un mot de passe

  • Il nous faut un moyen simple de garantir que seuls les modules du noyau présents sur une liste blanche puissent être chargés. J’en ai assez de devoir mettre en liste noire des modules dont personne n’a besoin

  • Je repose la question : pourquoi est-ce que c’est algif_aead qui prend tous les reproches dans copy.fail ? Le truc stupide, c’est authencesn.
    authencesn n’a pas été corrigé, et on en voit maintenant le résultat. Il s’avère qu’on peut atteindre la même écriture hors limites, ou probablement la même, via des sockets réseau ordinaires.
    J’aurais aimé y penser, mais ça ne m’est pas venu.
    [Édit : je parle du problème via ESP. Le problème RxRPC est, de ce que j’en comprends, totalement distinct]

  • Si ça fonctionne vraiment sur toutes les grandes distributions, ça me sidère encore de voir à quel point les mainteneurs sont irresponsables. Pourquoi activer par défaut des fonctions optionnelles du noyau qui ne servent probablement même pas à 0,1 % des utilisateurs ?
    Ça rappelle les distributions Linux de 1999 qui livraient une installation par défaut avec des dizaines de services réseau exposés sur Internet. Sauf qu’on n’est plus en 1999

    • Exiger d’un mainteneur de distribution qu’il mette certaines fonctionnalités en liste noire au motif que « tu n’en auras probablement pas besoin » (YAGNI), c’est beaucoup demander. Il ne peut pas savoir qui utilise quoi. Rien n’empêche l’utilisateur de revenir ensuite et d’ajuster la compilation à ses vrais besoins.
      Je me souviens de l’époque des débuts de Linux, quand on lançait make menuconfig pour ne sélectionner dans le noyau que les fonctions exactes qu’on voulait. Honnêtement, je n’ai pas envie d’y revenir.
      Cela dit, une cible facile d’amélioration ici, c’est RHEL. RHEL a tendance à intégrer directement beaucoup de choses dans le noyau au lieu de les laisser comme modules chargeables, ce qui rendait impossible une atténuation comme celle de copy fail. Peut-être qu’on pourrait réduire un peu ça
    • Il n’existe aucun moyen de désactiver les composants dont un utilisateur n’a probablement pas besoin sans rendre l’usage du système énormément plus difficile. Même après 25 ans sur cet OS idiot, je n’ai toujours aucun moyen de savoir quoi activer ou désactiver pour faire ce que je veux.
      Les mainteneurs de distributions Linux sont parmi les mainteneurs logiciels les plus responsables au monde. Leurs pratiques de sécurité sont bien meilleures que celles des gestionnaires de paquets des langages de programmation idiots ; ils maintiennent une sélection de paquets curée, examinent les changements, corrigent les bugs, résolvent des problèmes de packaging complexes, rétroporent les correctifs, utilisent des releases progressives, distribuent les fichiers via des miroirs dans le monde entier et vérifient cryptographiquement tous les fichiers. Sans oublier qu’ils font tout ça gratuitement
    • Ce n’est pas activé par défaut. Ce sont des modules optionnels chargés à la demande. Toute l’architecture du noyau consiste à compiler en dur les fonctions de base nécessaires à l’utilisateur, et à fournir presque tout le reste sous forme de modules chargés quand c’est nécessaire
    • À bien des égards, les ordinateurs non mobiles sont encore restés en 1999. Android est bien plus jeune et a eu l’occasion d’intégrer le contrôle d’accès obligatoire dans toute la pile, ce qui le rend bien plus sûr que les autres systèmes Linux
    • Pour exploiter ça, il faut déjà avoir un accès direct à l’ordinateur. Il faut un périphérique USB malveillant, une attaque de la chaîne logistique, ou l’exploitation d’un logiciel connu que l’utilisateur installera volontairement ou automatiquement. Et au-delà de ça, il faut en pratique pouvoir exécuter des commandes terminal arbitraires, ce qui constitue déjà une compromission majeure du confinement de ce logiciel.
      Si l’attaquant en est déjà là, la situation est déjà mauvaise. L’élévation de privilèges vers root est alors l’un des moindres soucis.
      Comme quelqu’un l’a mis plus bas : https://xkcd.com/1200/
      Avant de paniquer, il faut comprendre ce qu’est réellement cette vulnérabilité

  • Après toutes ces années, on a enfin atteint l’état « avec assez d’yeux, tous les bugs sont superficiels », et c’est plutôt nul. Va-t-il falloir faire des mises à jour du noyau plusieurs fois par semaine maintenant ?

    • Tu imagines vraiment quelqu’un entrer chez toi, trouver d’une manière ou d’une autre des identifiants par défaut, puis obtenir un accès root ?

  • Je me demande comment l’embargo a été rompu. Est-ce qu’il y a eu fuite, ou bien est-ce qu’un tiers l’a trouvé indépendamment ?

    • En réalité, l’embargo n’existe pas et ne peut pas exister.
      Linux est open source, donc tous les correctifs de bugs de sécurité sont visibles immédiatement par tout le monde. Vu le mode de développement du noyau, il n’y a aucun moyen d’y échapper. Ce que les gens appellent « embargo », c’est l’idée assez stupide selon laquelle, tant qu’on n’écrit pas noir sur blanc « THIS IS A LPE » dans la description du patch et qu’on garde le silence, on peut faire comme si la vulnérabilité n’avait pas fuité jusqu’au message « officiel » sur la mailing list.
      Cette approche était peut-être encore défendable autrefois, mais à l’ère des LLM, où l’on peut brancher automatiquement les diffs des mailing lists sur les derniers modèles pour leur faire identifier les patches qui corrigent des problèmes de sécurité, ce n’est plus seulement stupide, c’est dangereux
    • Le lien du patch a été posté sur le compte X de quelqu’un, puis quelqu’un d’autre l’a vu et a publié un exploit fonctionnel moins d’une heure plus tard. Il est possible que l’exploitation ait été accélérée par un LLM, mais à part ce délai très court, rien ne le prouve.
      https://x.com/encrypted_past/status/2052409822998392962
    • Un tiers sans lien avec l’affaire l’a publié publiquement

  • Quelqu’un sait si Debian est vulnérable ? J’ai essayé l’exploit sur des machines Debian 12 et Debian 13, mais je n’ai pas réussi à le reproduire moi-même

    • Je l’ai reproduit sur Debian 13, donc Trixie, avec le noyau 6.12.57+deb13-amd64, mais pas sur Debian 12 Bookworm avec le noyau 6.1.0-42-amd64.
      Pour ceux qui n’utilisent pas le flux de sécurité des paquets Debian sur Bookworm, le noyau 6.1.0-42-amd64 semble en fait immunisé contre copy.fail. C’est surprenant qu’il paraisse aussi immunisé contre dirtyfrag. Si le flux de sécurité ne l’a pas encore patché, on peut choisir une version du noyau qui conserve le commit 2b8bbc64b5c2. Je soupçonne que ce même commit rende aussi, par accident, certaines versions du noyau Debian 12 sûres face à dirtyfrag
    • Je viens d’essayer l’exploit sur une nouvelle droplet Debian 13 chez DigitalOcean, et ça a marché
    • Testé sur une Debian 13 entièrement à jour, et l’exploit fonctionne. J’ai aussi confirmé que l’atténuation fonctionne

  • Exécuté dans un conteneur ubuntu:latest avec un nouvel utilisateur par défaut
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Résultat : dirtyfrag: failed (rc=3)
    Bonne nouvelle !

    • J’ai obtenu le même résultat dans le conteneur, mais en l’exécutant directement sur l’hôte j’ai bien obtenu un shell. Ça montre seulement que l’exploit ne fonctionne pas à l’intérieur du conteneur. Cela ne veut pas dire que le conteneur n’est pas vulnérable, ou alors le script doit être ajusté pour fonctionner en conteneur
      copy fail peut servir à s’échapper d’un conteneur (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), donc je suppose qu’il ne faudrait que quelques petites modifications à l’exploit
    • J’aurais du mal à considérer un conteneur comme une plateforme fiable pour ce test. Qu’il s’agisse d’un comportement normal ou non, beaucoup de choses échouent dans les conteneurs
 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • Quelle sacrée semaine pour administrer des serveurs Linux partagés. Cela dit, j’apprécie que cette divulgation aille droit au but
    En revanche, je ne comprends pas pourquoi tout le monde masque stderr dans les consignes d’atténuation
    Édit : si ça a été signalé le 30 avril après avoir été « inspiré » par copy.fail, ça a donc été découvert en moins d’une journée ? Impressionnant
    Comme j’ai les droits sudo sur un serveur partagé assez important, je me demande aussi si compiler le noyau soi-même en n’incluant qu’un minimum de modules ne serait pas une bonne idée. Je n’ai pas étudié les avantages et inconvénients en profondeur, mais j’ai l’impression que cela aurait pu éviter les deux vulnérabilités d’élévation locale de privilèges de cette semaine
    Édit 2 :

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Oh, ça ne nécessite même pas de setuid. Bien vu de l’avoir inclus

    • C’est ce que je fais sur les systèmes multi-utilisateurs que je maintiens, et cela m’a effectivement permis d’éviter les deux exploits root locaux de cette semaine

  • Serait-il possible et raisonnable de récupérer la liste des modules du noyau chargés sur un système en fonctionnement, puis de l’utiliser comme liste d’autorisation modprobe pour ce système ?
    CopyFail et DirtyFrag semblent tous deux exploiter des modules du noyau qui n’étaient chargés sur aucun des systèmes que j’ai vérifiés. Dans ce cas, bloquer les modules manifestement inutiles ne permettrait-il pas d’atténuer préventivement certaines attaques ?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Je ne comprends pas comment ce genre de chose peut être toléré. Que des informations de cette ampleur circulent dans un environnement aussi peu fiable me paraît franchement aberrant

    • Je ne sais pas si le « tiers non lié » mentionné ici correspond à ce cas précis, mais pour information, Brad Spengler a repéré la vulnérabilité de sécurité suggérée par le message de commit après la mise en ligne du commit de correctif, puis quelqu’un dans les réponses a bricolé un exploit en vibe coding
      N’importe quel tiers surveillant les commits Linux aurait pu suivre les mêmes indices et produire un exploit
    • L’expression « tiers non lié » donne l’impression qu’il ne savait pas que ce bug était sous embargo
      Ici, l’« environnement peu fiable », c’est l’ensemble d’Internet, et il n’existe pas grand-chose qui ressemble à une véritable isolation. C’était déjà le cas avant, c’est simplement encore plus clair aujourd’hui. Voir aussi le billet récent de Stefan Eissing expliquant qu’un bug Apache httpd a été redécouvert deux fois avant sa correction

  • Existe-t-il un moyen de tester si les modules affectés ne peuvent vraiment pas être chargés ?
    Lors de CopyFail, j’ai fait une erreur en appliquant les premières mesures d’atténuation. Le nom du fichier dans /etc/modprobe.d/ ne se terminait pas par .conf, et je ne m’en suis rendu compte qu’après avoir exécuté la commande de test de https://news.ycombinator.com/item?id=47954159. Y a-t-il une commande similaire pour les modules esp4/esp6/rxrpc ?

    • J’ai essayé de charger les trois modules avec modprobe, et j’ai obtenu la même erreur que la dernière fois
      Il y a aussi le code de preuve de concept joint, mais je ne l’ai pas encore essayé