Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Test de copy.fail et d'un contournement

Première rédaction de cet article le 30 avril 2026
Dernière mise à jour le 2 mai 2026


Petit test de la faille de sécurité du noyau Linux copy.fail (CVE-2026-31431) sur une VM neuve.

La faille CVE-2026-31431 est très sérieuse (ainsi que DirtyFrag, qui l'a suivie d'une semaine). Premier avertissement : la sécurité, c'est compliqué et ne croyez donc pas aveuglément ce que j'écris ou ce que vous avez compris de cet article. Deuxième avertissement : les manipulations effectuées dans cet article sont dangereuses. Réservées aux adultes consentants.

J'ai créé une VM neuve chez xTom, avec le système Debian 13. Aucune modification de mon côté, c'est une Debian pure.

Le compte normal est toto. Il ne peut pas utiliser su sans le mot de passe de root :

toto@s55486:~$ id
uid=1000(toto) gid=1000(toto) groups=1000(toto),100(users)

toto@s55486:~$ su
Password: 
  

On télécharge le POC d'exploitation de la faille :

toto@s55486:~$ curl https://copy.fail/exp > copyfail
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   3458      0 --:--:-- --:--:-- --:--:--  3448

toto@s55486:~$ more copyfail 
#!/usr/bin/env python3
…
  

On l'examine mais, de toute façon, il est peu compréhensible. On le fait tourner (et je me répète, ne faites pas ça sur une machine de production !!!) :

toto@s55486:~$ python3 copyfail
# id
uid=0(root) gid=1000(toto) groups=1000(toto),100(users)

toto@s55486:~$ su
# 
  

Et voilà, on est root. (Il y a aussi une exploitation en C mais que je n'ai pas testée. Et une plus simple et plus analysable en Python.)

Pour empêcher cela, le mieux est d'installer un noyau réparé, s'il est disponible. C'est le cas dans Arch Linux, Debian, sur Ubuntu, Suse, Fedora… Si on n'a pas un tel noyau, on désactive le module noyau bogué :

root@s55486 ~ # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
root@s55486 ~ # rmmod algif_aead
  

toto@s55486:~$ python3 copyfail
Traceback (most recent call last):
  File "/home/toto/copyfail", line 9, in <module>
    while i<len(e):c(f,i,e[i:i+4]);i+=4
                   ~^^^^^^^^^^^^^^
  File "/home/toto/copyfail", line 5, in c
…
FileNotFoundError: [Errno 2] No such file or directory


toto@s55486:~$ su
Password: 
  

Et voilà, on est normalement en sécurité. (Il faut évidemment se protéger aussi contre DirtyFrag.) C'est par exemple ce qu'a fait NLNOG sur les machines du RING. Et Evolix nous donne une recette Ansible pour le faire sur toutes vos machines.

Si vous obtenez ceci :

% python copyfail
% 
  

C'est que vous utilisez un noyau non vulnérable (par exemple la version 7.0.2 qui dans Arch Linux).

Sinon, si vous préférez un POC en Go, ça existe (en C aussi).

Alain Thivillon me dit que sur les systèmes d'exploitation Red Hat comme Fedora le module est lié statiquement au noyau et il faut redémarrer avec ça sur la ligne de commande du noyau :

initcall_blacklist=algif_aead_init

(Ou utiliser seccomp. Mais je n'ai testé aucun des deux contournements sur une Red Hat. )

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)