dirtyfrag-arm64

Porting arm64/aarch64 di V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).

Testato su Ubuntu 24.04.4 LTS con linux-aws 6.17.0-1013-aws su AWS Graviton (il più recente disponibile al momento della scrittura).

Analisi completa con bypass di AppArmor, note di hardening e rilevamento: linnemanlabs.com/posts/porting-dirtyfrag-arm64

⚠️ Le restrizioni userns di AppArmor su Ubuntu non prevengono in modo affidabile questo exploit

Ubuntu ha due sysctl di AppArmor:

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

Entrambi possono essere bypassati concatenando aa-exec con se stesso utilizzando profili presenti nelle immagini standard di Ubuntu cloud e installer che ho testato:

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

Per maggiori informazioni, consulta Two Hops and a Shell per l'analisi completa del bypass di AppArmor su Ubuntu.

Cosa è diverso su arm64

Il PoC upstream x86_64 utilizza due percorsi di exploit: un percorso ESP/xfrm che corrompe /usr/bin/su e un fallback rxrpc/rxkad che corrompe /etc/passwd. Su arm64 il percorso rxrpc causa un kernel oops e non può essere utilizzato. Il percorso ESP funziona senza problemi.

Crash rxrpc: flush_dcache_page

Su x86_64, flush_dcache_page() è un no-op. x86 ha cache dati/istruzioni coerenti a livello hardware. Su arm64, esegue una vera manutenzione della dcache e dereferenzia i metadati struct page*. Quando il percorso crittografico rxrpc (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) chiama flush_dcache_page su una pagina il cui riferimento è stato manipolato attraverso la catena splice/vmsplice, x86_64 lo salta silenziosamente ma arm64 incontra un errore di traduzione e va in 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]

Sui sistemi arm64 che ho testato, negare la scrittura di uid_map ha rimosso il percorso ESP funzionante. Il namespace può ancora essere creato, ma il processo non può mapparsi come root al suo interno né ottenere le capacità necessarie per la configurazione XFRM. Il fallback rxrpc non ha fornito un percorso di escalation dei privilegi senza namespace funzionante su arm64, ha invece causato un oops del kernel.

Operazione solo ESP

Su arm64, solo il percorso ESP era praticabile nei miei test. Questo percorso richiede la creazione di un namespace utente e di rete e quindi il mapping dell'utente chiamante a root all'interno di quel namespace. L'hardening della distribuzione può rompere quel percorso in diversi modi: Ubuntu può negare la scrittura di uid_map tramite le restrizioni userns di AppArmor, non ho testato su Debian/RHEL.

AppArmor: bloccato per impostazione predefinita, aggirabile su Ubuntu

Sull'immagine AWS Ubuntu 24.04 che ho testato, apparmor_restrict_unprivileged_userns=1 ha bloccato lo sfruttamento diretto dalla mia normale shell SSH negando la scrittura di uid_map all'interno del nuovo namespace.

Tuttavia, con il valore predefinito apparmor_restrict_unprivileged_unconfined=0, un utente non confinato può passare a un profilo esistente in modalità complain (es. runc) tramite aa-exec e aggirare la restrizione:

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

Impostare kernel.apparmor_restrict_unprivileged_unconfined=1 blocca questo percorso ed è attualmente ampiamente raccomandato come soluzione per bloccare tutti i percorsi. Tuttavia, aggiungere un altro aa-exec aggira anche quello:

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

Vedi i post precedentemente linkati per i dettagli.

Payload specifico per architettura

L'exploit sovrascrive /usr/bin/su nella cache delle pagine con un ELF statico minimale. Il PoC upstream incorpora un ELF x86_64 con shellcode x86_64. Questo port lo sostituisce con un ELF aarch64 equivalente:

• ELF e_machine: EM_AARCH64 (183) invece di EM_X86_64 (62)
• Shellcode: istruzioni aarch64 che usano svc #0 invece di syscall
• Numeri di syscall: setgid=144, setuid=146, setgroups=159, execve=221 (vs 106, 105, 116, 59 su x86_64)
• Larghezza fissa delle istruzioni a 4 byte (vs x86_64 a lunghezza variabile), risultando in un payload leggermente più grande (~216 byte vs 192)

Compilazione ed esecuzione

# 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

Il flag --force-esp salta completamente il percorso rxrpc per evitare l'oops del kernel arm64.

Ambiente testato

Al 09-05-2026, l'ultimo kernel aws Ubuntu 24.04 disponibile (6.17.0-1013-aws, compilato il 24 aprile) viene fornito senza patch né per Copy Fail (CVE-2026-31431, divulgato il 29 aprile) né per Dirty Frag (CVE-2026-43284/43500, divulgato il 7 maggio).

Mitigazione immediata

Metti in blacklist i moduli vulnerabili, applica l'hardening di sistema appropriato per la tua distribuzione.

Metti in blacklist i moduli vulnerabili

Sicuro su qualsiasi sistema che non utilizzi attivamente la modalità di trasporto IPsec o AFS. Per impedire il caricamento dei moduli, inserisci quanto segue in /etc/modprobe.d/dirtyfrag.conf:

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

Aggiorna initramfs

Ubuntu consiglia anche di rigenerare initramfs in modo che la blacklist sia presente durante l'avvio iniziale:

update-initramfs -u -k all
``

### Rimuovi i permessi di lettura dai binari SUID

Blocca questa classe di attacco alla cache delle pagine basata su splice contro quei binari SUID. L'exploit necessita dei permessi di lettura al file target per `splice()`. Gli utenti possono ancora eseguire i binari.

**Non implementare questo senza testarlo nel tuo ambiente e su tutti i tuoi strumenti.**

```bash
chmod o-r /usr/bin/su

Questa non è una soluzione, solo una mitigazione. Ci sono molti altri percorsi per l'escalation dei privilegi.

Scarica i moduli

Per scaricare i moduli dal sistema in esecuzione:

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

Verifica che siano scaricati:

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

Svuota la cache delle pagine

Svuotare la cache delle pagine dovrebbe rimuovere i contenuti malevoli e far sì che i file vengano letti di nuovo dal disco.

echo 3 > /proc/sys/vm/drop_caches

Nota: ho avuto risultati incoerenti con questo, ma più provo a riprodurlo, più funziona come previsto. Per questo PoC, puoi controllare l'md5sum su /usr/bin/su e, se non corrisponde, riavvia.

Pulizia dopo i test

Esegui il passo di svuotamento della cache delle pagine, poi verifica con:

sha256sum /usr/bin/su

# O dal gestore pacchetti:

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

Mosse proattive

Per un approccio più proattivo che affronti questa intera classe di vulnerabilità (non solo i CVE specifici), consulta l'analisi completa per le restrizioni userns di AppArmor, la prevenzione del precaricamento dei moduli e il rilevamento runtime basato su Tetragon, così come le regole YARA.

Crediti

• Hyunwoo Kim (@v4bel) - ricerca originale della vulnerabilità, divulgazione e PoC x86_64
• SiCk - ricerca sul bypass-pwn del bypass di AppArmor su Ubuntu
• Keith Linneman / LinnemanLabs - porting arm64, analisi del crash flush_dcache_page, ricerca su AppArmor, note di rilevamento

Aspetti legali

Questo strumento è destinato esclusivamente a test di sicurezza e ricerca autorizzati.

L'uso non autorizzato contro sistemi che non possiedi o per i quali non hai esplicita autorizzazione è illegale e non etico.

Licenza

MIT. Copialo, rubalo, modificalo, impara da esso, condividi i tuoi miglioramenti con me. O non farlo. È codice, fai ciò che vuoi con esso.