Dirty Frag : une faille de sécurité de 9 ans d’âge dans le noyau Linux
Le début d'une série ?
Illustration : Flock
Le 11 mai à 13h00
Ce 7 mai, une nouvelle faille dans le noyau Linux permettant d’obtenir les droits superutilisateur a été divulguée. Mais l’embargo sur sa découverte a été cassé par des tiers. Même si un moyen de l’endiguer a été disponible rapidement, les responsables de distributions Linux courent depuis pour proposer à leurs utilisateurs un noyau incluant un patch.
Dirty Frag : une faille de sécurité de 9 ans d’âge dans le noyau Linux
Le début d'une série ?
Illustration : Flock
Ce 7 mai, une nouvelle faille dans le noyau Linux permettant d’obtenir les droits superutilisateur a été divulguée. Mais l’embargo sur sa découverte a été cassé par des tiers. Même si un moyen de l’endiguer a été disponible rapidement, les responsables de distributions Linux courent depuis pour proposer à leurs utilisateurs un noyau incluant un patch.
Sécurité
Sécurité
5 min
Ce week-end du 8 mai a été bien actif pour les administrateurs systèmes : un peu plus d’une semaine après la révélation de la faille Copy fail dans le noyau Linux, une autre vulnérabilité a été rendue publique le 7 mai dernier. Elle est maintenant décrite sous le nom de Dirty Frag.
Comme pour Copy fail, en l’exploitant, la faille permet une escalade des privilèges, c’est-à-dire qu’un utilisateur lambda d’une machine peut très facilement accéder aux droits d’accès superutilisateur et faire ce que bon lui semble. Encore faut-il avoir un compte sur la machine.
Embargo cassé
Cette faille a été détectée par le chercheur indépendant Hyunwoo Kim. Mais celui-ci n’avait pas prévu de diffuser l’information si tôt. Comme il l’a expliqué vendredi sur la liste de discussion oss-security, d’autres personnes ont outrepassé l’embargo fixé sur la divulgation de cette faille qui concerne la plupart des distributions Linux.
Ainsi, vendredi, au moment où il a posté le message, aucun patch n’existait et aucun numéro de vulnérabilité ne lui avait été affecté. Le seul moyen qu’il proposait pour endiguer son exploitation était de bloquer les modules dans lesquels le problème se trouvait via la commande :
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; echo 3 > /proc/sys/vm/drop_caches; true"
Depuis, la communauté s’est affairée à mettre tout en place pour bloquer la faille. Ainsi, Hyunwoo Kim a créé un dépôt GitHub officiel sur le sujet pour décrire et c’est en fait deux CVE qui ont été créées : CVE-2026-43284 puis CVE-2026-43500. Le score de vulnérabilité de la seconde n’est pas encore fixé mais celui de CVE-2026-43284 est de 8,8. Comme pour Copy Fail, le vecteur d’attaque est local (AV:L) : il faut déjà avoir un accès local sur la machine et le score aurait été sans doute plus élevé si ça n’avait pas été le cas.
Une modification possible depuis 2017
Les deux vulnérabilités se situaient aussi, comme avec Copy Fail, dans la possibilité de modifier le page cache (celui de xfrm-ESP depuis 2017 pour la CVE-2026-43284 et celui de RxRPC depuis 2023 pour la CVE-2026-43500). Corrigées respectivement depuis le 5 et 10 mai dans les deux projets, Hyunwoo Kim souligne qu’ « en d’autres termes, la durée de vie effective de ces vulnérabilités est d’environ 9 ans ».
La similarité avec Copy fail n’est pas étonnante puisque Hyunwoo Kim explique que c’est la première faille qui a inspiré sa recherche d’autres du même type
Le chercheur donne aussi un PoC. À Next, nous avons testé sur un serveur dédié virtuel chez OVHCloud sur lequel est installé Ubuntu 25.04. Nous avons pu reproduire le comportement, ainsi n’importe quelle personne qui a un compte sur la machine peut devenir root et y faire ce qu’elle veut.
Dans sa documentation, avant de pouvoir déployer le correctif de votre distribution, Hyunwoo Kim propose la même façon d’endiguer le problème que dans son message sur la liste oss-security.
Comme l’explique Ubuntu sur son blog, celle-ci peut poser des problèmes si on utilise le protocole de VPN IPSec comme le logiciel strongSwan. C’est aussi le cas si on se sert du système d’archivage distribué AFS (Andrew File System) « ou d’une autre application utilisant RxRPC ».
Course pour patcher
Petit à petit, les responsables des distributions Linux déploient un correctif. C’est le cas pour certaines versions de Debian, par exemple. Mais, à cause du non respect de l’embargo, le déploiement n’était pas prêt lorsque la faille a été rendue publique. Sur un dépôt GitHub titré « Copy Fail 2: Electric Boogaloo », d’autres personnes ont publié des informations sur la faille en marge du travail de Hyunwoo Kim tout en le créditant.
Celui-ci explique avoir contacté l’équipe de sécurité du noyau Linux le 30 avril avec un exploit montrant les possibilités d’utilisation de la faille et que le chercheur Kuan-Ting Chen a travaillé en parallèle sur le problème. Celui-ci a proposé un patch le 4 mai sur la liste netdev et il a été intégré à la branche netdev le 7 mai. Hyunwoo Kim a ensuite informé les responsables des distributions Linux sur la linux-distros et un embargo de cinq jours a été fixé. Mais celui-ci a donc été cassé par un tiers, ce qui a précipité la mise en place d’une solution. Comme avec Copy Fail, les administrateurs systèmes se sont donc retrouvés avec des informations partielles sur le problème au moment de la divulgation.
Commentaires (21)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
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-vousLe 11 mai à 13h12
Le 11 mai à 14h03
Le 11 mai à 14h11
Encore quelques failles comme ça et avec un peu de chance, le modèle de kernel monolithique avec 90% d’inutile dedans pour toi sera enfin remis en question…
Le 11 mai à 14h24
Le 11 mai à 14h31
Le 11 mai à 14h56
Le 11 mai à 14h58
Tout le monde n'a pas vocation à devenir expert du noyau.
Le 11 mai à 17h39
$ dpkg -l |grep "ii lib" |wc -l
2392
Je n’ai probablement pas la moindre idée de ce que fait la moitié de ces bibliothèques. Mais elles sont utiles à mon système, le mécanisme de dépendances fait que si elles sont installées, c’est qu’elles servent à un programme installé.
$ find -iname ".ko" |wc -l
4225
Ça fait deux fois plus. Et je n’ai pas non plus la moindre idée de ce que font au moins la moitié de ces modules. Par contre, il est certain que beaucoup de ces modules sont totalement inutiles sur mon système, qui n’aura jamais le matériel correspondant. Beaucoup pourraient faire l’objet de méta-paquets (comme on le fait déjà pour les firmwares par exemple).
C’était acceptable et accepté tant que ce n’était que de la place perdue. Maintenant que ça devient une source de problèmes, j’espère que les mentalités vont changer.
Le 11 mai à 16h57
Tu voulais peut-être dire : il faudrait un micro-noyau avec les drivers qui tournent en espace user.
Le 11 mai à 17h15
Le 11 mai à 18h29
On va y perdre un peu en user friendlyness, hein. Pour les plus jeunes qui n'ont pas connu cette ère glorieuse, ça leur fera goûter ce qu'était l'utilisation de Linux avant que udev et modprobe existent, la douce époque où il fallait charger un par un les modules correspondant à ton matériel dans
etc/modules. Personnellement, cette époque ne me manque pas.Le 11 mai à 21h59
Le 11 mai à 22h54
Le 11 mai à 19h38
C'est donc bien un problème pour les distributions plutôt que pour le kernel, non ?
Le 11 mai à 22h25
Sauf qu’en fait, l’autre conséquence négative, c’est de la surface d’attaque. Et autant la surface d’attaque sur des services utiles, elle est acceptable, sur des choses inutiles, c’est beaucoup plus discutable. Donc à mon humble avis, les choses vont évoluer de ce côté. Ça viendra probablement des distribs renforcées en premier, et peut-être que ça se propagera jusqu’au kernel. Si ce n’est pas à cette faille-ci, ce sera à une prochaine, on en trouve des pelletées en ce moment…
Le 11 mai à 23h11
Il y a en effet moyen sans doute de mieux gérer la diffusion des modules, mais dans le cadre de IPSec par exemple ça peut concerner de fait tout le monde car ce n'est pas lié à un matériel spécifique ni même à des usages très exotiques. Comme tout ce qui est réseau, cela risque d'être diffusé de manière globale car c'est délicat de définir "qui en a besoin ou pas".
Si on recentre la discussion sur le matériel, il y a déjà de tels enjeux pour les initramfs où de nombreux utilitaires comme dracut se base sur les modules chargés au moment de l'installation du nouveau noyau pour fournir les modules strictement nécessaires à l'initramfs. Mais ce n'est pas sans poser problèmes avec un matériel qui reste potentiellement modulaire en particulier pour des dispositifs comme le Wifi ou le Bluetooth avec des clés amovibles.
Il est possible de générer un paquet par module noyau (Yocto le fait déjà automatiquement), et il y a moyen certainement de coupler une installation automatique du paquet en fonction du matériel comme on peut le faire pour les imprimantes. Cependant, ça ajoute aussi des inconvénients. Je me souviens des déboires aussi avec Windows avec ce genre de modèle. Tu fais une conférence avec une télécommande infrarouge avec un dongle USB ? Faut prier qu'il trouve le pilote en live, il faut donc Internet et un peu de temps (et parfois, c'est long !). Ou plus chiant, tu veux le pilote Wifi mais tu n'as que le Wifi comme accès à Internet là où tu es... Des scénarios qu'on a déjà vécu et qui peuvent être aussi très embêtants.
Puis on peut se poser la question, la plupart des modules du noyau sont liés au matériel. Il reste peu probable qu'un module pour un matériel que ta machine n'a pas puisse avoir une faille de sécurité exploitable (car il ne pourra de toute façon pas se charger ou en mode dégradé qui limite les interactions possibles).
Tout est question de compromis, pour le pilote considéré ici, pas sûr que ton approche aurait changé grand chose, pour d'autres ça pourrait effectivement. Il y a aussi d'autres approches :
Le 12 mai à 22h43
Pas tout à fait. Mon propos, c’est de dire que le modèle de noyau monolithique encourage l’installation de modules par défaut, alors que très peu de gens en ont besoin. AndrewFS (puisqu’il fait partie des nominés pour dirtyfrag) est un vieux machin qui doit être utilisé dans 10 universités grand max. C’est effectivement beaucoup plus discutable pour ipsec, qui sert à beaucoup plus de monde, mais même ça ça pourrait ne pas être livré en standard, mais en dépendances d’autres paquets type strongswan. algif_aead, c’est largement pire, dans tous les articles que j’ai lu personne n’a été capable de dire à quoi il sert vraiment.
Oui. Je suis conscient des inconvénients. Mon propos est de dire qu’on va vers une inversion : les inconvénients d’avoir le module installé pourraient, dans bien des cas, dépasser celui de ne pas les avoir.
Oui. Une dernière que tu n’as pas évoquée, et qui aurait ici été efficace, est de bloquer, à un instant T après le démarrage de la machine, le chargement de nouveaux modules. À l’époque où je jouais avec gentoo hardened, j’avais mis un truc comme ça en place, et de mémoire, le blocage est irréversible (nécessite redémarrage pour débloquer). C’était d’ailleurs très chiant à l’usage pour un pc multi-usage, par contre pour un serveur dont le rôle est bien défini et le matos ne change pas ça se conçoit bien.
Modifié le 12 mai à 08h54
Perso je fais des noyau monolithique avec la config exacte de chaque machine, le reste est disable.
Après c'est casse tête : t'as l'interrogatoire de xconfig, et comme l'as remarqué un autre tu perds complètement le côté simple et plug & play... des linux modernes
Nouveau matos:
Modifié le 12 mai à 12h09
En plus pour une carte graphique aujourd'hui la majorité des fonctionnalités sont sous forme de logiciels liés au serveur graphique, qui s'installent et se mettent à jour sous forme de paquets et non dans le noyau qui n'a qu'un driver assurant juste la communication avec la carte et la gestion de la console texte avant démarrage du serveur graphique.
Pour tout ce qui est périphériques externes, ça repose habituellement sur des normes assez peu nombreuses (en grande majorité les classes USB) avec un driver générique par norme, on peut toutes les activer sans souci pour pouvoir brancher n'importe quoi. Et sur un serveur, à l'inverse on peut toutes les désactiver. Les systèmes de fichiers, pareil il y en a très peu de vraiment utilisés.
La mise à jour d'un noyau à l'autre se fait plutôt bien en récupérant la config actuelle disponible dans /proc/config.gz, en utilisant make oldconfig sur le nouveau noyau, et en répondant oui aux nouvelles fonctionnalités et non à tous les nouveaux drivers puisqu'ils ne nous concernent pas. Parfois, notamment s'il s'agit surtout de mises à jour de sécurité, il n'y a même pas de questions posées.
J'y touche un peu plus souvent pour rajouter une fonctionnalité nécessaire à un logiciel (par exemple Docker en demandait pas mal que je n'avais pas mises) que pour supporter un nouveau matériel. Mais ça reste rare et la distribution que j'utilise (Gentoo) me signale ce genre de manque à l'installation du paquet.
Après oui, je ne m'attends pas à ce que tout le monde le fasse, mais ceux qui pensent que le noyau est trop monolithique devraient s'y pencher, parce qu'en vrai, il ne l'a jamais été si on part des sources.
Le 13 mai à 09h32
après ça doit faire 20ans, et effectivement le seul gros changement pour ma part a été le passage 32bits => 64bits vers 2010 sinon c'est toujours la même install mise à jour en rolling release depuis. ~1x / an je jette un œil à la config du noyau pour arbitrer / nettoyer ce qui s'est ajouté depuis la dernière fois.
Modifié le 11 mai à 16h26
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?