linnemanlabs/dirtyfrag-arm64arm64/aarch64-Port von V4bel/dirtyfrag (CVE-2026-43284). Nur ESP - der rxrpc-Pfad verursacht auf arm64 Kernel-Oopses aufgrund von flush_dcache_page
arm64/aarch64-Port von V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).
Getestet auf Ubuntu 24.04.4 LTS mit linux-aws 6.17.0-1013-aws auf AWS Graviton (der zum Zeitpunkt dieses Schreibens neuesten verfügbaren Version).
Ausführlicher Bericht mit AppArmor-Bypass-Analyse, Härtungshinweisen und Erkennungshinweisen: linnemanlabs.com/posts/porting-dirtyfrag-arm64
Ubuntu hat zwei AppArmor-Sysctls:
Beide können umgangen werden, indem aa-exec mit sich selbst verkettet wird und dabei Profile verwendet werden, die in den von mir getesteten Standard-Ubuntu-Cloud- und Installer-Images vorhanden sind:
aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp
Weitere Informationen findest du unter Two Hops and a Shell mit der vollständigen Analyse des Ubuntu-AppArmor-Bypasses.
Das ursprüngliche x86_64-PoC verwendet zwei Exploit-Pfade: einen ESP/xfrm-Pfad, der /usr/bin/su korrumpiert, und einen rxrpc/rxkad-Fallback, der /etc/passwd korrumpiert. Auf arm64 verursacht der rxrpc-Pfad einen Kernel-Oops und kann nicht verwendet werden. Der ESP-Pfad funktioniert einwandfrei.
flush_dcache_pageUnter x86_64 ist flush_dcache_page() ein No-op. x86 verfügt über hardware-kohärente Daten-/Befehlscaches. Unter arm64 führt es echte dcache-Wartung durch und dereferenziert die struct page*-Metadaten. Wenn der rxrpc-Kryptopfad (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) flush_dcache_page auf einer Seite aufruft, deren Referenz über die splice/vmsplice-Kette manipuliert wurde, überspringt x86_64 dies stillschweigend, aber arm64 stößt auf eine Translation Fault und verursacht einen 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]
Auf den von mir getesteten arm64-Systemen entfernte das Verweigern des Schreibens auf uid_map den funktionierenden ESP-Pfad. Der Namespace kann zwar weiterhin erstellt werden, aber der Prozess kann sich darin nicht auf Root mappen und auch nicht die für das XFRM-Setup erforderlichen Namespace-Capabilities erlangen. Der rxrpc-Fallback bot auf arm64 keinen funktionierenden namespace-freien Privilege-Escalation-Pfad; stattdessen verursachte er einen Kernel-Oops.
Auf arm64 war in meinen Tests nur der ESP-Pfad nutzbar. Dieser Pfad erfordert das Erstellen eines User- und Network-Namespace und anschließend das erfolgreiche Mappen des aufrufenden Benutzers auf Root innerhalb dieses Namespace. Die Härtung der Distribution kann diesen Pfad auf verschiedene Weise blockieren: Ubuntu kann das Schreiben auf uid_map durch AppArmor-userns-Einschränkungen verweigern; auf Debian/RHEL habe ich nicht getestet.
Auf dem von mir getesteten Ubuntu-24.04-AWS-Image blockierte apparmor_restrict_unprivileged_userns=1 die direkte Ausnutzung aus meiner normalen SSH-Shell, indem das Schreiben auf uid_map innerhalb des neuen Namespace verweigert wurde.
Mit dem Standardwert apparmor_restrict_unprivileged_unconfined=0 kann ein unconfined-Benutzer jedoch über aa-exec in ein vorhandenes Profil im Beschwerdemodus (z. B. runc) wechseln und die Einschränkung umgehen:
aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp
Das Setzen von kernel.apparmor_restrict_unprivileged_unconfined=1 blockiert diesen Pfad und wird derzeit weithin als Lösung empfohlen, um alle Pfade zu blockieren. Das Hinzufügen eines weiteren aa-exec umgeht dies jedoch ebenfalls:
aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp
Details findest du in den zuvor verlinkten Beiträgen.
Der Exploit überschreibt /usr/bin/su im Page Cache mit einem minimalen statischen ELF. Das ursprüngliche PoC enthält ein x86_64-ELF mit x86_64-Shellcode. Dieser Port ersetzt es durch ein äquivalentes aarch64-ELF:
e_machine: EM_AARCH64 (183) statt EM_X86_64 (62)svc #0 statt syscall# 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
Das Flag --force-esp überspringt den rxrpc-Pfad vollständig, um den arm64-Kernel-Oops zu vermeiden.
| Eigenschaft | Wert |
|---|---|
| Instanz | AWS t4g.micro (Graviton2) |
| Betriebssystem | Ubuntu 24.04.4 LTS |
| Kernel | 6.17.0-1013-aws #13~24.04.1-Ubuntu (erstellt am 24.04.2026) |
| Architektur | aarch64 |
unprivileged_userns_clone | 1 (aktiviert) |
| esp4-Modul | verfügbar, ladbar |
| rxrpc-Modul | verfügbar, ladbar (verursacht auf arm64 jedoch einen Absturz) |
| Konfiguration | Standard-Ubuntu-24.04-Cloud-Image, Standard-Kernelmodule |
Zum Stand vom 09.05.2026 wird das neueste verfügbare Ubuntu-24.04-AWS-Kernel (6.17.0-1013-aws, erstellt am 24. April) ohne Patches für Copy Fail (CVE-2026-31431, offengelegt am 29. April) oder Dirty Frag (CVE-2026-43284/43500, offengelegt am 7. Mai) ausgeliefert.
Blackliste die verwundbaren Module und wende die für deine Distribution geeignete Systemhärtung an.
Sicher auf jedem System, das nicht aktiv den IPsec-Transportmodus oder AFS verwendet. Um das Laden der Module zu verhindern, lege Folgendes in /etc/modprobe.d/dirtyfrag.conf ab:
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
Ubuntu empfiehlt außerdem, das Initramfs neu zu erzeugen, damit die Blacklist während des frühen Bootvorgangs vorhanden ist:
update-initramfs -u -k all
``
### Entferne Leseberechtigungen von SUID-Binaries
Dies blockiert diese splice-basierte Page-Cache-Angriffsklasse gegen diese SUID-Binary-Ziele. Der Exploit benötigt für `splice()` Leseberechtigungen an der Zieldatei. Benutzer können die Binaries weiterhin ausführen.
**Setze dies nicht um, ohne es in deiner Umgebung und mit all deinen Werkzeugen getestet zu haben.**
```bash
chmod o-r /usr/bin/su
Das ist keine Lösung, sondern nur eine Abschwächung. Es gibt viele weitere Wege zur Privilege-Escalation.
Um die Module aus dem laufenden System zu entladen:
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null
Stelle sicher, dass sie entladen sind:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
&& echo "Affected modules are loaded" \
|| echo "Affected modules are NOT loaded"
Das Leeren des Page Cache sollte die schädlichen Inhalte entfernen und dazu führen, dass die Dateien erneut von der Disk gelesen werden.
echo 3 > /proc/sys/vm/drop_caches
Hinweis: Ich habe damit einige inkonsistente Ergebnisse gehabt, aber je mehr ich versuche, es zu reproduzieren, desto mehr funktioniert es wie erwartet. Für dieses PoC kannst du die md5sum von /usr/bin/su prüfen; wenn sie nicht übereinstimmt, starte neu.
Führe den Schritt zum Leeren des Page Cache aus und verifiziere anschließend mit:
sha256sum /usr/bin/su
# Or from package manager: