La société Theori a publié un exploit (écrit avec Python 3.10) pour le noyau Linux x86-64 pour passer root en local. Il utilise un bug dans les sockets AF_ALG sur une opération AEAD qui existe depuis 2017 (commit). Depuis d'autres exploits ont été écrits tels quel copy-fail-c qui est écrit en C et supporte d'autres architectures CPU (comme AArch64); sous Fedora, il a besoin du paquet glibc-static.
Le correctif (commit) est disponible dans le noyau Linux 7.0. Référez-vous aux documentations de votre distribution pour les backports vers les noyaux plus anciens:
La faille "copy.fail" écrit dans des pages de cache du système de fichier. C'est une primitive simple, fiable et efficace pour écrire un exploit. Le chercheur Taeyang Lee étudiait la surface d'attaque AF_ALG, puis d'autres chercheurs de Theori l'ont rejoint. L'outil Xint Code aidé par l'IA a accéléré la recherche : lire l'article pour les détails.
L'exploit écrit dans des pages de cache. Exécuter sync && echo 3 >/proc/sys/vm/drop_caches (pour vider le cache) ou rebooter la machine annule l'effet de l'exploit.
Il existe plusieurs manières de bloquer l'exploit comme ajouter initcall_blacklist=algif_aead_init à la ligne de commande du noyau Linux, ou bloquer le module noyau algif_aead sur les distributions qui le compilent comme module (CONFIG_CRYPTO_USER_API_AEAD=m dans le config noyau).
# Blocage exploit sous Debian 13
Posté par Pat _ . Évalué à 3 (+2/-0). Dernière modification le 30 avril 2026 à 17:05.
Alors sous Debian (13 pour moi) c'est un peu trompeur.
le kernel est compilé avec les options :
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_USER_API_AEAD=m
rmmod algif_aead fonctionne, le module est déchargé……..
l'exploit fonctionne toujours.
création de /etc/modprobe.d/copyfail-mitigation.conf contenant blacklist algif_aead
et reboot……..
l'exploit fonctionne toujours !
Il faut en plus ajouter le initcall_blacklist=algif_aead_init à la ligne de commande du kernel et après reboot, enfin il ne fonctionne plus. Ouf !
Donc ce n'est pas l'une ou l'autre méthode, mais les deux qu'il faut appliquer.
[^] # Re: Blocage exploit sous Debian 13
Posté par Ambroise . Évalué à 2 (+1/-0).
Le link du module vers /bin/false marche également sur debian
Voir dans le site du bug où l'exploit est présenté.
Ce qui est dommage, c'est qu'ils n'expliquent pas pourquoi le blacklist ne suffit pas…
[^] # Re: Blocage exploit sous Debian 13
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
https://wiki.debian.org/fr/KernelModuleBlacklisting explique bien pourquoi blacklist ne marche pas.
[^] # Re: Blocage exploit sous Debian 13
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Encore mieux, appliquer le contournement documenté par les découvreurs de la faille, 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf'
# Chercheurs en sécurité pas très sérieux
Posté par Damien Thébault . Évalué à 5 (+3/-0).
Normalement on doit laisser suffisamment de temps pour que les correctifs puissent être disponible le jour où on communique sur la faille trouvée.
Ici, bien qu'ils aient informé le noyau Linux il y a 1 mois, ils n'ont pas du tout contacté les distributions.
Ils leur suffisaient pourtant de suivre ce qui était écrit dans la documentation du noyau correspondante et d'envoyer un email à la mailing-list linux-distros.
On se retrouve au final avec effectivement un patch dans le dernier kernel, mais sans backport dans les versions utilisées par les distributions, et avec très peu d'utilisateurs protégés lors de la divulgation, ce qui n'est à mon avis pas professionnel de leur part.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.