dirtyfrag-arm64

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-AppArmor-userns-Einschränkungen verhindern diesen Exploit nicht zuverlässig

Ubuntu hat zwei AppArmor-Sysctls:

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

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.

Was sich auf arm64 unterscheidet

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.

rxrpc-Absturz: flush_dcache_page

Unter 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.

Nur-ESP-Betrieb

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.

AppArmor: standardmäßig blockiert, unter Ubuntu umgehbar

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.

Architekturspezifisches Payload

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:

• ELF e_machine: EM_AARCH64 (183) statt EM_X86_64 (62)
• Shellcode: aarch64-Anweisungen mit svc #0 statt syscall
• Syscall-Nummern: setgid=144, setuid=146, setgroups=159, execve=221 (vs. 106, 105, 116, 59 auf x86_64)
• Feste 4-Byte-Befehlsbreite (vs. x86_64 mit variabler Länge), was zu einem etwas größeren Payload führt (~216 Bytes vs. 192)

Erstellen und Ausführen

# 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.

Getestete Umgebung

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.

Sofortige Gegenmaßnahmen

Blackliste die verwundbaren Module und wende die für deine Distribution geeignete Systemhärtung an.

Blackliste die verwundbaren Module

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

Initramfs aktualisieren

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.

Entlade die Module

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"

Page Cache leeren

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.

Aufräumen nach dem Testen

Führe den Schritt zum Leeren des Page Cache aus und verifiziere anschließend mit:

sha256sum /usr/bin/su

# Or from package manager:

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

Proaktive Maßnahmen

Für eine proaktivere Haltung, die diese gesamte Verwundbarkeitsklasse adressiert (nicht nur die spezifischen CVEs), siehe den ausführlichen Bericht zu AppArmor-userns-Einschränkungen, zur Verhinderung des Vorladens von Modulen sowie zur Tetragon-basierten Laufzeiterkennung und zu YARA-Regeln.

Danksagungen

• Hyunwoo Kim (@v4bel) - ursprüngliche Sicherheitsforschung, Offenlegung und x86_64-PoC
• SiCk - Bypass-pwn-Forschung zum Ubuntu-AppArmor-Bypass
• Keith Linneman / LinnemanLabs - arm64-Port, Analyse des flush_dcache_page-Absturzes, AppArmor-Forschung, Erkennungshinweise

Rechtliche Hinweise

Dieses Tool ist ausschließlich für autorisierte Sicherheitstests und Forschung bestimmt.

Die unbefugte Verwendung gegen Systeme, die du nicht besitzt oder für die du keine ausdrückliche Genehmigung zum Testen hast, ist illegal und unethisch.

Lizenz

MIT. Kopiere es, stiehl es, modifiziere es, lerne daraus, teile deine Verbesserungen mit mir. Oder lass es. Es ist Code, mach damit, was du willst.