dirtyfrag-arm64

Port arm64/aarch64 de V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).

Testé sur Ubuntu 24.04.4 LTS avec linux-aws 6.17.0-1013-aws sur AWS Graviton (le plus récent disponible au moment de cette rédaction).

Analyse complète avec analyse de contournement d'AppArmor, notes de durcissement et de détection : linnemanlabs.com/posts/porting-dirtyfrag-arm64

⚠️ Les restrictions userns d'AppArmor d'Ubuntu n'empêchent pas de manière fiable cette exploitation

Ubuntu a deux sysctls AppArmor :

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

Les deux peuvent être contournés en chaînant aa-exec avec lui-même en utilisant des profils présents sur les images cloud et d'installation standard d'Ubuntu que j'ai testées :

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Pour plus d'informations, consultez Two Hops and a Shell pour l'analyse complète du contournement d'AppArmor d'Ubuntu.

Qu'est-ce qui est différent sur arm64

Le PoC x86_64 amont utilise deux chemins d'exploitation : un chemin ESP/xfrm qui corrompt /usr/bin/su, et un repli rxrpc/rxkad qui corrompt /etc/passwd. Sur arm64, le chemin rxrpc provoque un kernel oops et ne peut pas être utilisé. Le chemin ESP fonctionne proprement.

Crash rxrpc : flush_dcache_page

Sur x86_64, flush_dcache_page() est une opération nulle. x86 a des caches de données/instructions cohérents matériellement. Sur arm64, elle effectue une vraie maintenance du dcache et déréférence les métadonnées struct page*. Lorsque le chemin crypto rxrpc (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) appelle flush_dcache_page sur une page dont la référence a été manipulée via la chaîne splice/vmsplice, x86_64 l'ignore silencieusement mais arm64 rencontre une erreur de traduction et provoque un oops :

pc : flush_dcache_page+0x18/0x58
lr : skcipher_walk_done+0xbc/0x260
     crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc]
     crypto_skcipher_encrypt+0x48/0xb8
     rxkad_secure_packet+0x108/0x270 [rxrpc]
     rxrpc_send_data+0x264/0x550 [rxrpc]

Sur les systèmes arm64 que j'ai testés, le refus de l'écriture sur uid_map a supprimé le chemin ESP fonctionnel. L'espace de noms peut toujours être créé, mais le processus ne peut pas se mapper en tant que root à l'intérieur ni obtenir les capacités d'espace de noms nécessaires pour la configuration XFRM. Le repli rxrpc n'a pas fourni de chemin fonctionnel d'élévation de privilèges sans espace de noms sur arm64, il a plutôt provoqué un oops du noyau.

Opération ESP uniquement

Sur arm64, seul le chemin ESP était viable dans mes tests. Ce chemin nécessite de créer un espace de noms utilisateur et réseau, puis de mapper avec succès l'utilisateur appelant en root dans cet espace de noms. Le durcissement de la distribution peut casser ce chemin de différentes manières : Ubuntu peut refuser l'écriture sur uid_map via les restrictions userns d'AppArmor, je n'ai pas testé sur Debian/RHEL.

AppArmor : bloqué par défaut, contournable sur Ubuntu

Sur l'image AWS Ubuntu 24.04 que j'ai testée, apparmor_restrict_unprivileged_userns=1 bloquait l'exploitation directe depuis mon shell SSH normal en refusant l'écriture sur uid_map dans le nouvel espace de noms.

Cependant, avec la valeur par défaut apparmor_restrict_unprivileged_unconfined=0, un utilisateur non confiné peut passer dans un profil existant en mode complain (ex. runc) via aa-exec et contourner la restriction :

aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp

Définir kernel.apparmor_restrict_unprivileged_unconfined=1 bloque ce chemin, et est largement recommandé actuellement comme solution pour bloquer tous les chemins. Cependant, ajouter un autre aa-exec contourne également cela :

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Voir les articles liés précédemment pour les détails.

Charge utile spécifique à l'architecture

L'exploit écrase /usr/bin/su dans le cache de pages avec un ELF statique minimal. Le PoC amont intègre un ELF x86_64 avec du shellcode x86_64. Ce port le remplace par un ELF aarch64 équivalent :

• ELF e_machine : EM_AARCH64 (183) au lieu de EM_X86_64 (62)
• Shellcode : instructions aarch64 utilisant svc #0 au lieu de syscall
• Numéros d'appels système : setgid=144, setuid=146, setgroups=159, execve=221 (vs 106, 105, 116, 59 sur x86_64)
• Largeur d'instruction fixe de 4 octets (vs longueur variable x86_64), résultant en une charge utile légèrement plus grande (~216 octets contre 192)

Construction et exécution

# Clone
git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git

# Build
cd dirtyfrag-arm64
gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil

# Run
./dirtyfrag_arm64 --force-esp

Le drapeau --force-esp ignore complètement le chemin rxrpc pour éviter le oops du noyau arm64.

Environnement testé

Au 2026-05-09, le dernier noyau aws Ubuntu 24.04 disponible (6.17.0-1013-aws, construit le 24 avril) est livré sans correctifs ni pour Copy Fail (CVE-2026-31431, divulgué le 29 avril) ni pour Dirty Frag (CVE-2026-43284/43500, divulgué le 7 mai).

Atténuation immédiate

Mettez en liste noire les modules vulnérables, appliquez le durcissement système approprié pour votre distribution.

Mettre en liste noire les modules vulnérables

Sûr sur tout système n'utilisant pas activement le mode transport IPsec ou AFS. Pour empêcher le chargement des modules, mettez ce qui suit dans /etc/modprobe.d/dirtyfrag.conf :

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Mettre à jour l'initramfs

Ubuntu recommande également de régénérer l'initramfs pour que la liste noire soit présente lors du démarrage précoce :

update-initramfs -u -k all

Supprimer les permissions de lecture des binaires SUID

Bloque cette classe d'attaque basée sur splice dans le cache de pages contre ces cibles binaires SUID. L'exploit a besoin des permissions de lecture sur le fichier cible pour splice(). Les utilisateurs peuvent toujours exécuter les binaires.

Ne mettez pas cela en œuvre sans l'avoir testé dans votre environnement et sur tous vos outils.

chmod o-r /usr/bin/su

Ce n'est pas un correctif, seulement une atténuation. Il existe de nombreux autres chemins vers l'élévation de privilèges.

Décharger les modules

Pour décharger les modules du système en cours d'exécution :

rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

Assurez-vous qu'ils sont déchargés :

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "Affected modules are loaded" \
  || echo "Affected modules are NOT loaded"

Vider le cache de pages

Vider le cache de pages devrait supprimer le contenu malveillant et faire en sorte que les fichiers soient lus à nouveau depuis le disque.

echo 3 > /proc/sys/vm/drop_caches

Note : j'ai eu des résultats incohérents avec cela, mais plus j'essaie de le reproduire, plus cela fonctionne comme prévu. Pour ce PoC, vous pouvez vérifier le md5sum de /usr/bin/su, et s'il ne correspond pas, redémarrez.

Nettoyage après les tests

Exécutez l'étape de vidage du cache de pages, puis vérifiez ensuite avec :

sha256sum /usr/bin/su

# Or from package manager:

dpkg -V util-linux    # Debian/Ubuntu
rpm -V util-linux     # RHEL/Amazon Linux

Mesures proactives

Pour une posture plus proactive qui aborde toute cette classe de vulnérabilités (pas seulement les CVE spécifiques), consultez l'analyse complète pour les restrictions userns d'AppArmor, la prévention du préchargement des modules, et la détection en temps réel basée sur Tetragon ainsi que les règles YARA.

Crédits

• Hyunwoo Kim (@v4bel) - recherche originale de vulnérabilité, divulgation et PoC x86_64
• SiCk - recherche de contournement-pwn sur le contournement d'AppArmor d'Ubuntu
• Keith Linneman / LinnemanLabs - port arm64, analyse du crash flush_dcache_page, recherche AppArmor, notes de détection

Légal

Cet outil est destiné uniquement aux tests de sécurité et à la recherche autorisés.

L'utilisation non autorisée contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester est illégale et contraire à l'éthique.

Licence

MIT. Copiez-le, volez-le, modifiez-le, apprenez-en, partagez vos améliorations avec moi. Ou non. C'est du code, faites-en ce que vous voulez.