● Next INpact Télécom 📅 30/04/2026 à 13:40

Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root

Géopolitique 👤 Martin Clavey
Illustration
Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root Une optimisation trop rapide Illustration : Flock Martin Clavey Le 30 avril à 13h40 Depuis 2017, une vulnérabilité dans le module cryptographique authencesn du noyau Linux laissait à un compte d’un simple utilisateur la possibilité de passer en root. Elle concerne la plupart des grandes distributions jusqu’au déploiement du patch, qui est déjà en cours. Une erreur ? C’est l’entreprise de sécurité Xint.io qui a révélé, ce mercredi 29 avril, cette vulnérabilité (CVE-2026-31431, d’une sévérité élevée de 7,8/10) permettant une élévation des privilèges en local. Le score n’est « que » de 7,8 car le vecteur d’attaque est local (AV:L) : il faut déjà avoir un accès local sur la machine, ici un compte utilisateur. La même avec une attaque depuis le réseau (AV:N) se serait approchée de 10. N’importe qui peut devenir root Appelée « Copy Fail », celle-ci permet (sans accès au réseau, sans utiliser de fonctionnalités de débogage du noyau et sans avoir installé quoique ce soit avant) à toute personne possédant un simple compte utilisateur sur quasiment n’importe quelle distribution Linux d’obtenir les privilèges root et donc d’y faire tout ce qu’elle veut. Comme l’explique l’entreprise sur le site dédié à la faille, « un utilisateur local sans privilèges peut écrire quatre octets contrôlés dans le page cache de n’importe quel fichier accessible en lecture sur un système Linux, et s’en servir pour obtenir les privilèges root ». Les responsables des distributions ont commencé à mettre à jour le paquet de leur noyau Linux pour bloquer l’utilisation d’une faille de sécurité qui se situait directement dans le noyau. Le danger concerne les systèmes partagés entre plusieurs utilisateurs, les clusters de conteneurs (Kubernetes, Docker…), etc. Un utilisateur lambda pourrait ainsi accéder aux données des autres utilisateurs. Une faille dans le module cryptographique authencesn du noyau Xint.io explique que cette faille a été découverte par le chercheur de l’entreprise Theori, Taeyang Lee, en étant assisté par l’IA de son outil Xint Code alors qu’il étudiait la manière dont le sous-système de cryptographie de Linux interagit avec les données stockées dans le page cache. C’est un système de cache qui permet au noyau d’avoir un accès plus rapide à certaines informations. Sécurité Comment survivre à la déferlante à venir des vulnérabilités identifiées par IA ? (3/3) Sécurité Lundi 27 avril 2026 à 13h19 27/04/2026 13h19 5 De fait, c’est un bug dans le module cryptographique authencesn du noyau Linux qui est en cause, accessible via l’interface de socket AF_ALG, en combinaison avec l’appel système splice(). « Un utilisateur peut ouvrir un socket, le lier à n’importe quel modèle AEAD (chiffrement authentifié avec données associées) et lancer le chiffrement ou le déchiffrement de données arbitraires. Aucun privilège n’est requis », explique Xint. De son côté, la fonction splice() transfère des données entre les descripteurs de fichiers et les pipes sans les copier, en renvoyant simplement les page caches par référence. En utilisant un script Python très court (732 octets) qui ne fait appel qu’à des bibliothèques standard et ciblant le page cache du noyau, il est possible d’accéder au binaire qui permet d’être superutilisateur : /usr/bin/su. La modification se fait en mémoire, pas directement sur le périphérique de stockage. Une ligne de commande suffit… Nous l’avons testé sur un de nos VPS avec Ubuntu 24.04 LTS, nous sommes bien passés en root avec une seule ligne de commande en utilisant le script Python : Les chercheurs ont constaté la faille sur les distributions Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 ou encore SUSE 16 et expliquent logiquement que « les autres distributions utilisant les noyaux concernés — Debian, Arch, Fedora, Rocky, Alma, Oracle, ainsi que les distributions embarquées — présentent le même comportement ». Un patch pour le noyau a déjà été proposé et accepté. Celui-ci supprime une optimisation des opérations AEAD qui avait été ajoutée en 2017. « Mettez à jour le paquet du noyau de votre distribution avec une version incluant le commit a664bf3d603d de la branche principale », expliquent les chercheurs, « la plupart des principales distributions proposent désormais ce correctif », comme Debian, Ubuntu, Suse, ou encore chez Red Hat, par exemple. 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-vous ben51 Premium Il y a 14 minutes Message 1 Signaler Bloquer cet utilisateur moche Eglyn Il y a 11 minutes Voir les réponses Message 2 Aller au commentaire enfant Signaler Bloquer cet utilisateur la plupart des principales distributions proposent désormais ce correctif », comme Debian, Ubuntu, Suse, ou encore chez Red Hat, par exemple.--> Non, pas Debian en tout cas.J'ai patché toutes les workstations avec le correctif proposé : echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.confrmmod algif_aead 2>/dev/null bilbonsacquet Premium Modifié il y a 6 minutes Voir les réponses En réponse à Message 2.1 Historique Aller au commentaire enfant Signaler Bloquer cet utilisateur Sur mes debian, le module n'a jamais été activé :rmmod: ERROR: Module algif_aead is not currently loaded Eglyn À l'instant En réponse à Message 2.1.1 Signaler Bloquer cet utilisateur De mon côté j'ai testé le script python, et j'ai pu passer root tranquillou sur une Debian 13 T_TDonc patch en urgences des workstations :) bingo.crepuscule Premium Il y a 8 minutes Voir les réponses Message 3 Aller au commentaire enfant Signaler Bloquer cet utilisateur La bonne nouvelle c'est qu'une ribambelle de matos non mis à jour par les fabricants, va pouvoir être rooté et modifiés.On peut se demander s'il va être possible de rooter sur Android des appareils dont le bootloader est verrouillé ? sohka Premium Il y a 2 minutes En réponse à Message 3.1 Signaler Bloquer cet utilisateur Grâce au confinement selinux et/ou le filtrage seccomp, probablement pas. Et encore heureux. koocotte Premium Il y a 5 minutes Message 4 Signaler Bloquer cet utilisateur Actuellement, je ne vois aucun correctif sur les pages indiquées, ni pour Debian, ni pour Ubuntu, ni pour Suse, ni pour Red Hat. Il y a bien une page à propos de la CVE qui indique les versions affectées, mais pas encore de paquet correctif. Mavelic Premium Il y a 4 minutes Message 5 Signaler Bloquer cet utilisateur Si linux fait comme windows, ça va devenir de plus en plus facile de migrer ! Oxygen Premium À l'instant Message 6 Signaler Bloquer cet utilisateur Aucune distrib n'est encore à jour.Cette vuln est un fail magistral des process de patching sous NDA des équipes upstream.Et il faudra sérieusement se poser la question de QUI a introduit ce commit en 2017.side node:les désactivations du module marchent sur les distrib à module.Sur les EL & dérivés, il faut modifier le bootloader grub pour désactiver la feature qui est kernel native.La synthèse que j'ai faite:To perform this, you need to edit the grub settings in GRUB_CMDLINE_LINUX by adding initcall_blacklist=algif_aead_init into /etc/default/grubThen proceed to activate the new grub config by running grub2-mkconfig -o /boot/grub2/grub.cfgThen reboot. Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ? Non Oui
← Retour