Journal Exploit Linux local pour passer root : Copy Fail (CVE-2026-31431)

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
30
avr.
2026

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  . Évalué à 6 (+5/-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.

  • # Chercheurs en sécurité pas très sérieux

    Posté par  . Évalué à 10 (+25/-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.

    • [^] # Re: Chercheurs en sécurité pas très sérieux

      Posté par  . Évalué à 8 (+7/-0). Dernière modification le 30 avril 2026 à 21:21.

      Par contre, ils ont osé mettre sur leur site

      Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.

      Alors que aucune grosse distro ne contient le patch. Pire, leur workaround ne marche pas sur certaines distributions (les RHEL et leurs dérivées…)

    • [^] # Re: Chercheurs en sécurité pas très sérieux

      Posté par  (site web personnel, Mastodon) . Évalué à 10 (+17/-0).

      Y'a rien de professionnel dans leur façon de faire, c'est du foutage de gueule intégral et ils ont préféré être dangereux pour pouvoir se faire mousser.

      Outre ce que tu dit :

      • Pas d'information claire sur les versions touchées et corrigées du noyau
      • Proof of concept proposé à base de curl <URL> | bash…
      • … Avec une URL qui renvoie autre chose que le Python de test si on y accède avec un navigateur au lieu de curl ou wget
      • Site ultra inquiétant sur une CVE notée 7.8 https://www.cve.org/CVERecord?id=CVE-2026-31431 parce que nécessite un compte local

      Mais ils ont très bien réussi leur coup de communication, y'a plein de gens en panique qui racontent n'importe quoi sur le sujet, quitte à proposer des "solutions" impossibles comme "Mettre à jour les noyaux Linux vers une version 7.x le plus vite possible".

      À en lire les Internets, on croirait qu'on est face à un nouveau Log4Shell, alors que pas du tout

      La connaissance libre : https://zestedesavoir.com

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.