CVE-2026-31431 : Copy Fail - ELF statique de 587 octets

Je n'ai pas trouvé ce bug. Le crédit revient à Xint Code / Theori.

Ce dépôt est ma tentative de rendre l'exploit aussi petit que possible - un ELF x86_64 fait main qui réalise l'intégralité de l'élévation de privilèges en 587 octets. Pas de libc, pas de linker, pas de runtime. Juste NASM et de l'obstination.

En substance, le noyau vous offre une primitive d'écriture dans le cache de pages de n'importe quel fichier lisible via AF_ALG + splice. Pointez-la vers le point d'entrée d'un binaire setuid, écrivez le shellcode, exécutez le binaire, root.

Pour le contexte sur la taille : le post public original de Copy Fail a publié une petite version Python mesurée à 732 octets. C'est extrêmement cool, mais elle dépend toujours de la présence du runtime Python. Encore plus petit, il y a https://kopy.fail à 524 octets. Celui-ci en revanche est un ELF statique brut : pas d'interpréteur, pas de libc, pas de linker, pas de chargeur dynamique. (ma maman dit que c'est cool)

Le Bug

AF_ALG permet à l'espace utilisateur de faire de la crypto noyau via des sockets. Pour les chiffrements AEAD comme authencesn, le noyau accepte les données via sendmsg avec MSG_MORE, puis vous pouvez splicer plus de données depuis un descripteur de fichier.

La partie maudite : lorsque vous splices un fichier, le noyau épingle les pages du cache de pages du fichier directement dans la liste scatter-gather crypto. L'opération AEAD écrit ensuite sa sortie dans ces mêmes pages. Le noyau pense avoir donné à la crypto un tampon de lecture. La crypto pense avoir reçu un tampon d'écriture. Personne ne copie.

Les octets que vous fournissez comme métadonnées AAD finissent visibles à travers le cache de pages. Toute lecture ultérieure de ce fichier - par n'importe quel processus, n'importe quel utilisateur, y compris l'exécution suid - voit les données corrompues. Le fichier sur disque est intact. Seule la vue du cache de pages en mémoire change.

Nommage

Copy Fail est la malédiction de la famille cache de pages/COW qui se manifeste sous les habits d'AF_ALG. Même lignée que Dirty COW (CVE-2016-5195) - « le noyau vous a laissé écrire dans quelque chose que vous ne devriez pouvoir que lire » - mais via le chemin de splice crypto au lieu de la course madvise/write.

Exploitation

Cible : /bin/su sur Debian Bookworm (y compris le rootfs kernelCTF). Le point d'entrée ELF se situe à l'offset fichier 0x3910.

28 octets de shellcode le transforment en un dropper de shell root :

; setuid(0) - 7 octets
31 ff           xor edi, edi
6a 69           push 105
58              pop rax
0f 05           syscall
; execve("/bin/sh", NULL, NULL) - 21 octets
99              cdq
31 f6           xor esi, esi
48 bb 2f 62 69 6e 2f 73 68 00   movabs rbx, "/bin/sh\0"
53              push rbx
54              push rsp
5f              pop rdi
6a 3b           push 59
58              pop rax
0f 05           syscall

La primitive AEAD ne vous donne que 4 octets par opération - un morceau de 32 bits de l'AAD atterrit à l'offset de splice. 28 octets de shellcode ÷ 4 = 7 passages à travers la pile crypto du noyau. Chaque itération :

1. socket(AF_ALG) + bind avec authencesn(hmac(sha1),cbc(aes))
2. setsockopt pour définir la clé et la taille du tag d'authentification
3. accept pour obtenir le fd de requête
4. sendmsg avec MSG_MORE - l'iov de 8 octets contient 4 octets de remplissage AAD + 4 octets de shellcode
5. splice depuis /bin/su à travers un pipe vers le fd de requête (positionne les pages du cache de pages)
6. recvfrom - déclenche le traitement AEAD, corrompt le cache de pages
7. Tout fermer (critique - un état AF_ALG périmé corrompt les splices suivants)

Après les 7 itérations, execve("/bin/su"). Le noyau le charge depuis le cache de pages corrompu. L'exécution saute vers le point d'entrée écrasé. Shell root.

Le Binaire

587 octets au total. 120 d'entre eux sont l'en-tête ELF (le noyau ne vous chargera pas sans lui), donc la logique réelle de l'exploit est de 467 octets de code machine + données.

Voici où les choses se trouvent dans l'en-tête ELF :

Offset  Champ           Utilisation réelle
------  -----           ----------
0x00    e_ident[0:8]    magic + classe ELF (obligatoire)
0x08    e_ident[8:16]   matériel de clé crypto (le noyau ignore ces octets)
0x28    e_shoff         chaîne "/bin/su\0" (le noyau ignore pour ET_EXEC)

Le noyau ne regarde que e_ident[0:7], e_type, e_machine, e_entry, e_phoff, e_phnum, et le phdr lui-même. Tout le reste est de l'espace libre.

Autres astuces de taille :

• Un seul PT_LOAD RWX, BSS pour le sockaddr_alg de 88 octets (le noyau le met à zéro)
• Tous les syscalls encodés comme push imm8 / pop rax / syscall (3 octets chacun)
• Le compteur de boucle dans r14 compte de 24→0 par pas de -4, sert aussi d'index de shellcode
• Registres choisis pour survivre aux syscalls (r12=fd_cible, r15=fd_alg, rbp=fd_requête, rbx=base_shellcode) pour ne pas gaspiller d'octets à les recharger

L'histoire 584→587

La première version fonctionnelle faisait 584 octets. Elle utilisait mov ax, 275 pour le deuxième appel splice (2 octets plus court que mov eax, 275). Cela parie que le premier splice réussit toujours - s'il retourne une erreur négative, les 48 bits supérieurs de rax restent définis, et mov ax, 275 n'écrase que les 16 bits inférieurs. Ensuite, le numéro de syscall du deuxième splice est du garbage.

Sur mon noyau de test, cela a toujours fonctionné. Mais « toujours fonctionne en test » est une mauvaise raison pour livrer un bug, et si quelqu'un tombe dessus sur un système où splice retourne EAGAIN sous pression mémoire, l'exploit segfaulte simplement sans indication de ce qui a mal tourné. J'ai avalé les 3 octets supplémentaires.

J'ai aussi dû ajouter xor esi, esi avant le execve final parce que recvfrom écrase rsi avec l'adresse du tampon. Sans cela, execve reçoit un pointeur argv garbage. Encore un octet.

Compilation

nasm -f bin -o copy_fail_v3 copy_fail_v3.asm && chmod +x copy_fail_v3

Nécessite NASM. Produit directement le binaire de l'exploit - aucune étape de liaison.

Utilisation

$ id
uid=1000(user) gid=1000(user) groups=1000(user)
$ ./copy_fail_v3
# id
uid=0(root) gid=0(root) groups=0(root)

Prend moins d'une seconde. Aucune sortie en cas de succès - juste un shell root.

Noyaux Affectés

Nécessite CONFIG_CRYPTO_USER_API_AEAD (intégré ou module chargé) et le chemin de splice en place non corrigé dans algif_aead. Le mauvais chemin de code remonte à une optimisation de 2017. Vérifiez la configuration du noyau et l'état des correctifs de votre distribution.

Correctif

Le correctif supprime le chemin en place et copie les pages sources du splice au lieu de les aliaser dans la liste scatter-gather crypto. L'isolation du cache de pages est rétablie.

Ne soyez pas stupide

Ceci est un artefact KernelCTF/laboratoire. Exécutez-le sur des systèmes que vous possédez ou pour lesquels vous avez une permission explicite de tester. Si vous défendez des machines Linux, corrigez le noyau ou restreignez le chargement du module AF_ALG/algif_aead.

Daniel Wade - GitHub · Twitter/X · Bluesky · nadsec.online