Copy Fail (CVE-2026-31431) — Laboratoire de reproduction d'exploit et de détection

Ce dépôt documente la reproduction de bout en bout, l'ingénierie de détection et la réponse aux incidents pour CVE-2026-31431 (« Copy Fail »), une vulnérabilité critique d'élévation de privilèges locale dans le noyau Linux affectant les noyaux 4.14 à 7.0-rc.

Principaux résultats

✅ Exploitation réussie de CVE-2026-31431 sur Kali Linux 2026.1 (noyau 6.18.12+kali-amd64)
✅ Déploiement de règles de détection au niveau des appels système avec auditd
✅ Création de règles Sigma et YARA pour une détection multiplateforme
✅ Élaboration d'un playbook complet de réponse aux incidents

Pourquoi c'est important

Copy Fail est un défaut de logique, et non une corruption de mémoire. Il est déterministe, affecte pratiquement toutes les distributions Linux publiées depuis 2017, et est totalement sans fichier — la surveillance traditionnelle de l'intégrité des fichiers (AIDE, Tripwire) ne peut pas le détecter. Une preuve de concept fonctionnelle tient en seulement 732 octets de Python.

Environnement du laboratoire

Composant	Détails
Hyperviseur	VirtualBox
VM cible	Kali Linux 2026.1
Noyau	6.18.12+kali-amd64
PoC d'exploit	theori-io/copy-fail-CVE-2026-31431
Détection	auditd, Sigma, YARA

Étapes de reproduction

1. Vérifier la version de Kali et le noyau

Le laboratoire commence par confirmer que la cible exécute un noyau vulnérable.

Version de Kali Détails de la version et du noyau de Kali Linux 2026.1.

Version du noyau Sortie de uname -r montrant le noyau vulnérable 6.18.12+kali-amd64.

2. Vérifier la présence du module vulnérable

L'exploit nécessite le module noyau algif_aead et le modèle cryptographique authencesn.

Module chargé lsmod et modinfo confirment que algif_aead est disponible ; /proc/crypto montre le modèle vulnérable authencesn.

3. Version de Python

Le PoC utilise os.splice, qui nécessite Python 3.10+. Nous vérifions l'interpréteur.

Version de Python Python 3.12 est installé et prêt.

4. Vérificateur de vulnérabilité (non destructif)

Avant d'exécuter l'exploit complet, un vérificateur sûr confirme que le système est vulnérable.

Vérificateur de vulnérabilité Le vérificateur signale « potentiellement vulnérable », ouvrant la voie à l'exploitation.

5. Créer un utilisateur non privilégié

Un compte testuser non privilégié est créé pour simuler un attaquant sans droits particuliers.

ID de testuser id affiche l'UID 1001, confirmant un accès non root.

6. Cloner et exécuter l'exploit

Le PoC officiel de Theori est cloné et exécuté depuis le compte non privilégié.

PoC cloné Le dépôt de l'exploit a été cloné avec succès.

Exécution de l'exploit L'exploit Python écrase le cache de pages et déclenche le binaire /usr/bin/su corrompu.

Shell root obtenu Les sorties de whoami et id prouvent une élévation complète vers root.

7. Vérifier la nature sans fichier (aucune modification du disque)

L'exploit ne corrompt que le cache de pages en mémoire. Le fichier /usr/bin/su sur le disque conserve sa somme de contrôle d'origine.

Correspondance SHA256 Le sha256sum correspond au hachage d'origine du paquet même après l'exploitation, confirmant l'absence de modification du disque.

Ingénierie de détection

Copy Fail ne peut pas être détecté par la surveillance de l'intégrité des fichiers. Nous nous concentrons plutôt sur les primitives au niveau des appels système qu'il utilise.

Règles auditd

Nous déployons des règles auditd personnalisées qui se déclenchent sur :

la création de sockets AF_ALG (famille 38)
l'utilisation de l'appel système splice()
l'accès en lecture aux binaires setuid par des processus non privilégiés

Règles auditd chargées Toutes les règles personnalisées sont actives, vérifiées avec auditctl -l.

Après avoir exécuté l'exploit une seconde fois, nous voyons des alertes pour les appels système exacts utilisés :

Alerte auditd – Socket AF_ALG ausearch affiche un événement de création de socket AF_ALG provenant du processus testuser.

Alerte auditd – splice() ausearch affiche un événement splice() provenant du même PID, une forte corrélation.

Règle Sigma

Une règle Sigma traduit les résultats d'auditd dans un format SIEM neutre vis-à-vis des fournisseurs.

Règle Sigma Règle YAML Sigma détectant la création de sockets AF_ALG et les appels splice().

Règle YARA

Une règle YARA aide à identifier le code de l'exploit Copy Fail sur le disque.

Règle YARA correspondant à la chaîne authencesn, aux constantes de socket et aux références splice() trouvées dans les PoC.

Récapitulatif de la couverture de détection

Couche	Ce qu'elle voit	Statut
auditd	Socket AF_ALG + appels système splice	✅ Déployé
Sigma	Motifs d'appels système via SIEM	✅ Règle prête
YARA	Code PoC sur le disque	✅ Règle prête
FIM (AIDE/Tripwire)	Modifications de fichiers	❌ Aveugle – aucune écriture disque ne se produit

Playbook de réponse aux incidents

Un rapport complet de réponse aux incidents est disponible dans reports/incident-copy-fail.md. Il comprend :

Résumé exécutif
Indicateurs de compromission (IoCs)
Cartographie MITRE ATT&CK (T1068, T1611)
Étapes de confinement et d'éradication
Enseignements tirés concernant les attaques sans fichier

Atténuation

Atténuation immédiate (aucun redémarrage requis) :

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead

Populaires

Copy-Fail-CVE-2026-31431-Lab