Faille Linux Copy Fail
Une faille critique a été trouvée sur Linux, système pourtant le plus sûr du monde jusqu'à présent.
Copy Fail (CVE-2026-31431) : 732 octets de Python pour rooter Linux depuis 2017
Theori vient de divulguer une LPE kernel qui touche toutes les distributions Linux sorties depuis 2017, avec une fiabilité de 100% et zéro offset à ajuster.
Le même script Python de 732 octets (stdlib uniquement) root Ubuntu, Amazon Linux, RHEL et SUSE sans modification, ce qui est extrêmement rare pour une LPE kernel.
La faille se niche dans algif_aead, l'interface AF_ALG qui expose le crypto API du kernel aux applis userspace.
Une optimisation in-place introduite en 2017 permet, en chaînant avec splice(), de faire pointer la destination scatterlist d'un chiffrement authentifié sur des pages du page cache appartenant à un binaire setuid comme /usr/bin/su.
4 octets contrôlés écrits dans le page cache suffisent à patcher le contrôle de permission en mémoire.
Le fichier sur disque n'est pas touché (donc AIDE, Tripwire et consorts passent à côté), et comme le page cache est partagé au niveau de l'hôte, la modification traverse les frontières de containers.
Conséquence directe : un pod compromet le nœud Kubernetes, une PR malveillante prend la main sur un runner CI, un notebook tenant devient root sur la machine SaaS.
Mitigation immédiate avant patch :
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf && rmmod algif_aead.
Rien de critique ne passe par AF_ALG (dm-crypt, kTLS, IPsec, OpenSSL, SSH utilisent le crypto API directement), donc le coût opérationnel est nul pour la majorité des systèmes.
Détail qui mérite qu'on s'y arrête : la faille a été trouvée par Xint Code, un agent d'audit propulsé par LLM, après une heure de scan sur le sous-système crypto/.
8 ans de relectures humaines, 1 heure d'agent. PoC et timeline de divulgation sur copy.fail.
FAQ
Est-ce que ma machine Linux est vulnérable ?
Si tu utilises une distribution Linux sortie depuis 2017 (Ubuntu, RHEL, SUSE, Amazon Linux, entre autres), tu es potentiellement exposé. La faille touche le module kernel algif_aead, présent sur l'écrasante majorité des systèmes modernes.
Comment se protéger rapidement sans attendre un patch officiel ?
Tu peux désactiver le module algif_aead en deux commandes : ajouter une règle dans modprobe.d et décharger le module à chaud. Les services courants comme OpenSSL, SSH, IPsec ou dm-crypt ne passent pas par AF_ALG, donc cette désactivation n'a pratiquement aucun impact sur ton système.
Est-ce qu'un antivirus ou un outil de surveillance d'intégrité comme Tripwire aurait pu détecter l'attaque ?
Non. L'attaque modifie uniquement le page cache en mémoire, sans jamais toucher les fichiers sur disque. Les outils qui comparent les empreintes de fichiers passent donc complètement à côté.
Est-ce que la faille est dangereuse dans un environnement cloud ou Kubernetes ?
Particulièrement oui. Comme le page cache est partagé au niveau de l'hôte, une exploitation depuis un container peut compromettre le nœud Kubernetes entier, un runner CI ou une machine SaaS, au-delà des frontières d'isolation habituelles.
Comment cette faille a-t-elle été découverte après 8 ans ?
Elle a été identifiée par Xint Code, un agent d'audit basé sur un LLM, en à peine une heure d'analyse du sous-système crypto du kernel. Ce résultat relance le débat sur la limite des revues de code humaines pour ce type de vulnérabilité profondément enfouie.
Alexandre P.
Développeur passionné depuis plus de 20 ans, j'ai une appétence particulière pour les défis techniques et changer de technologie ne me fait pas froid aux yeux.
Poursuivre la lecture
