DIRTY FRAG Detection con Wazuh 4.14.4 - CVE-2026-43284 / CVE-2026-43500

Detection engineering per la Linux Kernel LPE Dirty Frag - Ubuntu / RHEL / Debian / Amazon Linux

Cos'è Dirty Frag?

CVE-2026-43284 / CVE-2026-43500 è una vulnerabilità di escalation locale dei privilegi (LPE) nel kernel Linux che combina due primitive indipendenti di scrittura nella page cache per ottenere root da un account utente non privilegiato. Un singolo binario compilato riesce a ottenere root su tutte le principali distribuzioni Linux. Nessuna race condition. Nessuno heap spray. Nessun offset del kernel richiesto.

Variante 1 - CVE-2026-43284 (xfrm-ESP):``` unshare(CLONE_NEWUSER|CLONE_NEWNET) -> register XFRM SA via netlink (CAP_NET_ADMIN inside new namespace) -> vmsplice(ESP header into pipe) -> splice(target file into pipe) -> splice(pipe to UDP socket) -> esp_input() in-place AEAD decrypt writes 4 bytes into page cache

**Variante 2 - CVE-2026-43500 (RxRPC):**```
add_key("rxrpc", ...)       no privileges required
-> socket(AF_RXRPC=35)
-> RxRPC handshake + forged DATA packet
-> vmsplice(RxRPC wire header into pipe)
-> splice(target file into pipe)
-> splice(pipe to UDP socket)
-> rxkad_verify_packet_1() in-place pcbc(fcrypt) decrypt writes 8 bytes into page cache

Quando CLONE_NEWUSER è bloccato da AppArmor (impostazione predefinita di Ubuntu 24.04+), l'exploit ripiega automaticamente dalla variante ESP alla variante RxRPC. Lo stesso binario ottiene root in entrambi i casi.

CRITICO: La mitigazione Copy Fail (blacklist di algif_aead) non protegge da Dirty Frag. Entrambe le vulnerabilità condividono lo stesso sink authencesn, ma Dirty Frag viene innescato attraverso un percorso di codice completamente diverso. Se hai implementato la mitigazione Copy Fail, sei comunque esposto.

Scoperta e pubblicata da V4bel - https://github.com/V4bel/dirtyfrag

Riferimenti Ufficiali

Perché FIM Fallisce - Perché Esiste Questo Repo

Dirty Frag scrive direttamente nella cache delle pagine in memoria. Il binario su disco non viene mai modificato. Il kernel non marca mai la pagina corrotta come sporca, quindi il writeback non viene mai eseguito. Il file su disco è identico byte per byte all'originale prima e dopo lo sfruttamento.``` Traditional FIM approach: read file from disk -> compute hash -> compare -> no anomaly reported

Dirty Frag reality: on-disk /usr/bin/su = UNCHANGED page cache of /usr/bin/su = CONTAINS ROOT SHELL ELF FIM result = BLIND

L'unico rilevamento efficace è comportamentale, tramite il monitoraggio delle syscall a livello di kernel. Questo repository fornisce regole Wazuh validate in produzione che rilevano entrambe le varianti dell'exploit a livello di syscall, indipendentemente dalla versione del kernel o dallo stato delle patch.

---

## Catena di exploit```
ESP variant (CVE-2026-43284):
  unshare(CLONE_NEWUSER)    privilege boundary bypass via user namespace
  -> XFRM SA registration  CAP_NET_ADMIN gained inside new netns
  -> vmsplice()        [!]  ESP header planted into pipe
  -> splice()          [!]  /usr/bin/su page cache enters pipe
  -> splice()               pipe delivered to UDP socket
  -> esp_input() decrypt    4 bytes written deterministically into page cache
  -> execve(/usr/bin/su)    corrupted setuid binary runs shellcode as UID 0

RxRPC variant (CVE-2026-43500):
  add_key("rxrpc")          session key K planted - no privileges needed
  -> socket(AF_RXRPC)       rxrpc.ko auto-loaded
  -> vmsplice()        [!]  RxRPC wire header planted into pipe
  -> splice()          [!]  /etc/passwd page cache enters pipe
  -> splice()               pipe delivered to UDP socket
  -> rxkad_verify_packet_1() 8 bytes written deterministically into page cache
  -> su -                   /etc/passwd root entry has empty password field

La corruzione della page cache è la primitiva fondamentale in entrambe le varianti. vmsplice inserisce l'header di protocollo controllato dall'attaccante in una pipe. splice trasferisce le pagine della page cache del file target nella stessa pipe senza copiarle. Quando il kernel elabora il buffer combinato attraverso il percorso di decrittazione, scrive i byte controllati dall'attaccante nella page cache del file target.

Sistemi interessati

Confermato da @m0us3r - laboratorio di rilevamento su Ubuntu 24.04.2 LTS

Confermato dall'autore (github.com/V4bel/dirtyfrag)

Tutti i kernel Linux dal 2017 sono interessati. La restrizione AppArmor unprivileged_userns su Ubuntu 24.04+ blocca la variante ESP, ma la variante RxRPC la aggira completamente.

CVE-2026-43284 (ESP): in scope dal commit cac2661c53f3 (2017-01-17) fino a f4c50a4034e6 (2026-05-05) - CORRETTO nella mainline

CVE-2026-43500 (RxRPC): in scope dal commit 2dc334f1a63a (2023-06-08) fino a upstream - NESSUNA PATCH ANCORA DISPONIBILE

Struttura del Repository```

DIRTY-FRAG-Detection-with-Wazuh-4.14.4/ | |- rules/ | '- local_rules.xml # 9 Wazuh detection rules (200000-200008) | |- auditd/ | '- cve-dirty-frag.rules # auditd syscall sensor rules (v2 - auid fix) | |- sca/ | '- cve-dirty-frag.yml # SCA policy - kernel-version independent | '- docs/ |- dirty_frag_dash_rules.png # Wazuh Rules Management - 200000-200008 deployed and active |- SCA.png # SCA policy score 50% - 3 passed / 3 failed |- SCA-hits.png # Wazuh Discover - SCA check results across 3 scan cycles |- discover-dirty-frag.png # Wazuh Discover - 52 hits - initial validation run (May 8) '- discover-dirty-frag_more.png # Wazuh Discover - 13 hits - chain rule 200007 level 15 (May 15)

> **Nota su local_rules.xml:** Le regole sono fornite in `local_rules.xml`, che è il file Wazuh standard per le regole personalizzate in `/var/ossec/etc/rules/local_rules.xml`. Se preferisci mantenere le tue regole di rilevamento organizzate per CVE, puoi distribuire il contenuto come file autonomo (es. `cve-2026-43284_rules.xml`) nella stessa directory. Entrambi gli approcci funzionano allo stesso modo.

---

## Architettura di rilevamento

Due livelli indipendenti - nessuno dei due dipende dalla versione del kernel o dallo stato delle patch.

### Livello 1 - Rilevamento comportamentale (auditd + Wazuh)

**Nota importante su uid vs auid:** Il processo figlio della variante ESP chiama `unshare(CLONE_NEWUSER)` e si mappa come `uid=0` all'interno del nuovo user namespace. Il sottosistema di audit di Linux registra l'uid locale al namespace negli eventi SYSCALL, il che significa che i filtri `-F uid!=0` non catturano gli eventi `vmsplice` e `splice` del processo figlio dell'exploit. `auid` (audit uid / login uid) viene impostato al momento del login e non cambia mai con il ri-mappaggio del namespace. Le regole del sensore per `vmsplice` e `splice` usano `-F auid>=1000` per catturare correttamente il vero utente di login indipendentemente da ciò che l'exploit fa all'interno del namespace.

**Regole del sensore Auditd** (`auditd/cve-dirty-frag.rules`):```
-a always,exit -F arch=b64 -S vmsplice -F auid>=1000 -F auid!=-1 -k dirty_frag_vmsplice
-a always,exit -F arch=b32 -S vmsplice -F auid>=1000 -F auid!=-1 -k dirty_frag_vmsplice
-a always,exit -F arch=b64 -S splice   -F auid>=1000 -F auid!=-1 -k dirty_frag_splice
-a always,exit -F arch=b32 -S splice   -F auid>=1000 -F auid!=-1 -k dirty_frag_splice
-a always,exit -F arch=b64 -S unshare  -F uid!=0                  -k dirty_frag_ns_escape
-a always,exit -F arch=b64 -S add_key  -F uid!=0                  -k dirty_frag_add_key
-a always,exit -F arch=b64 -S socket   -F a0=0x23 -F uid!=0       -k dirty_frag_rxrpc_socket
-w /usr/bin/kmod -p x                                             -k dirty_frag_modload
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/su -F auid>=1000 -F auid!=-1 -k dirty_frag_execve_su

Livello 2 - Superficie di vulnerabilità (SCA Policy)

Controlli di configurazione automatizzati tramite sca/cve-dirty-frag.yml. Vengono eseguiti ogni 12 ore su tutti gli agenti registrati. Nessun controllo della versione del kernel richiesto.

Architettura della catena di regole

Nota di ingegneria: Le regole della catena (200007/200008) scattano quando due segnali dello stesso processo arrivano entro 120 secondi. vmsplice seguito da splice dallo stesso pid è la sequenza principale di innesto nella pipe per entrambe le varianti. Una socket AF_RXRPC seguita da splice dallo stesso pid è specifica del percorso RxRPC. Entrambe le catene vengono validate tramite wazuh-logtest con esito 9/9.

Wazuh Dashboard - Regole distribuite

Regole 200000-200008 distribuite e attive. Tag di conformità: PCI_DSS, HIPAA, GDPR, NIST_800_53, MITRE ATT&CK. Le regole 200007 e 200008 raggiungono il livello 15 (Critico) in caso di rilevamento di catene correlate.

Distribuzione

Passo 1 - Installare auditd```bash

Ubuntu / Debian

apt install auditd audispd-plugins -y systemctl enable --now auditd auditctl -s | grep enabled

RHEL / Amazon Linux

yum install audit -y systemctl enable --now auditd

SUSE

zypper install audit -y systemctl enable --now auditd

### Passo 2 - Distribuire le regole del sensore auditd```bash
cp auditd/cve-dirty-frag.rules /etc/audit/rules.d/
augenrules --load
auditctl -l | grep dirty_frag

Il contenuto del chunk 17 è vuoto: non è presente testo da tradurre.``` -a always,exit -F arch=b64 -S vmsplice -F auid>=1000 -F auid!=-1 -F key=dirty_frag_vmsplice -a always,exit -F arch=b32 -S vmsplice -F auid>=1000 -F auid!=-1 -F key=dirty_frag_vmsplice -a always,exit -F arch=b64 -S splice -F auid>=1000 -F auid!=-1 -F key=dirty_frag_splice -a always,exit -F arch=b32 -S splice -F auid>=1000 -F auid!=-1 -F key=dirty_frag_splice -a always,exit -F arch=b64 -S unshare -F uid!=0 -F key=dirty_frag_ns_escape -a always,exit -F arch=b64 -S add_key -F uid!=0 -F key=dirty_frag_add_key -a always,exit -F arch=b64 -S socket -F a0=0x23 -F uid!=0 -F key=dirty_frag_rxrpc_socket -w /usr/bin/kmod -p x -k dirty_frag_modload -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/su -F auid>=1000 -F auid!=-1 -F key=dirty_frag_execve_su

### Passo 3 - Distribuisci le regole di rilevamento Wazuh

Accoda il contenuto di `rules/local_rules.xml` al tuo file `/var/ossec/etc/rules/local_rules.xml` esistente, oppure distribuiscilo come file autonomo se preferisci mantenere le regole organizzate per CVE:```bash
# Option A - append to local_rules.xml (recommended)
cat rules/local_rules.xml >> /var/ossec/etc/rules/local_rules.xml

# Option B - standalone file
cp rules/local_rules.xml /var/ossec/etc/rules/cve-2026-43284_rules.xml

Poiché il contenuto non è stato fornito nel messaggio, non posso tradurlo. Per favore invia il testo del chunk 21 da tradurre.```bash

Validate syntax - must exit 0 with zero warnings

/var/ossec/bin/wazuh-analysisd -t 2>&1 | tail -5

Restart manager

systemctl restart wazuh-manager

### Step 4 - Distribuire la policy SCA```bash
# On the Wazuh manager - distribute to all agents via shared group
cp sca/cve-dirty-frag.yml /var/ossec/etc/shared/default/
chown root:wazuh /var/ossec/etc/shared/default/cve-dirty-frag.yml
chmod 660 /var/ossec/etc/shared/default/cve-dirty-frag.yml

Aggiungi alla configurazione del gruppo agenti (/var/ossec/etc/shared/default/agent.conf):```xml <agent_config> /var/ossec/etc/shared/cve-dirty-frag.yml </agent_config>

> **Richiesto:** L'esecuzione remota dei comandi deve essere abilitata su ogni agente affinché i controlli `c:lsmod` e `c:systemctl` vengano eseguiti:
>
> ```bash
> echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
> systemctl restart wazuh-agent
> ``````bash
systemctl restart wazuh-manager

Passo 5 - Configura ossec.conf localfile

Assicurati che l'agente Wazuh acquisisca il log di auditd. Aggiungi all'interno di <ossec_config> in /var/ossec/etc/ossec.conf su ciascun host monitorato, oppure distribuisci tramite agent.conf:```xml <log_format>audit</log_format> /var/log/audit/audit.log

---

## Validazione

### wazuh-logtest - tutte e 9 le regole```bash
# SIGNAL 1 - vmsplice (rule 200000)
echo 'type=SYSCALL msg=audit(1778261582.230:1155): arch=c000003e syscall=316 success=yes exit=8 a0=3 a1=7fff00000000 a2=1 a3=0 items=0 ppid=1000 pid=93321 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=58 comm="exp" exe="/home/kr/exp" subj=unconfined key="dirty_frag_vmsplice"' | /var/ossec/bin/wazuh-logtest 2>&1 | grep -E "rule|level|200"

# SIGNAL 7 - CHAIN ESP (rules 200000 + 200007, same pid)
printf 'type=SYSCALL msg=audit(1777570010.000:200): arch=c000003e syscall=316 success=yes exit=8 a0=3 a1=7fff00000000 a2=1 a3=0 items=0 ppid=1000 pid=55001 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=58 comm="exp" exe="/home/kr/exp" key="dirty_frag_vmsplice"\ntype=SYSCALL msg=audit(1777570011.000:201): arch=c000003e syscall=275 success=yes exit=4 a0=4 a1=5 a2=6 a3=0 items=0 ppid=1000 pid=55001 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=58 comm="exp" exe="/home/kr/exp" key="dirty_frag_splice"\n' | /var/ossec/bin/wazuh-logtest 2>&1 | grep -E "rule|level|200"

Atteso per il test della catena:``` id: '200000' level: '10' <- vmsplice signal id: '200007' level: '15' <- CHAIN ESP confirmed - IMMEDIATE INVESTIGATION REQUIRED

### Verifica che auditd abbia catturato gli eventi dopo l'esecuzione dell'exploit```bash
ausearch -k dirty_frag_vmsplice --start today 2>/dev/null | grep "exe=" | head -5
ausearch -k dirty_frag_ns_escape --start today 2>/dev/null | grep "exe=" | head -5
ausearch -k dirty_frag_execve_su --start today 2>/dev/null | grep "EUID=" | head -5

Verifica degli avvisi generati da Wazuh```bash

grep -E "200002|200005|200006" /var/ossec/logs/alerts/alerts.log | tail -10

Punteggio SCA previsto (sistema di base senza sensore o auditd distribuito): **50%** (3 superati / 3 falliti).

---

## Evidenze di validazione in produzione

### Esecuzione dell'exploit - agente wazuh5beta (Ubuntu 24.04.2 LTS kernel 6.8.0-111-generic)```
kr@wazuh5beta:~$ ./exp
root@wazuh5beta:~# date ; uname -a ; id ; whoami
Sat May 9 04:59:08 AM UTC 2026
Linux wazuh5beta 6.8.0-111-generic #111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026 x86_64
uid=0(root) gid=0(root) groups=0(root)
root

L'utente kr (uid=1000) senza privilegi ha eseguito il binario PoC e ha ottenuto una shell di root (uid=0). Wazuh ha rilevato e allertato in tempo reale.

Esecuzione di validazione iniziale - 8 maggio 2026 (52 riscontri)

Contesto: Questa esecuzione è stata effettuata prima che le regole complete del sensore auditd venissero distribuite. Le regole 200002, 200005 e 200006 sono scattate tramite la copertura auditd di base. La regola di catena completa (200007) richiede che il file sensore cve-dirty-frag.rules sia attivo - vedere l'esecuzione di validazione completa più sotto.

Esecuzione di validazione completa - attivazione della regola di catena 200007 (15 maggio 2026)

La regola 200007 è scattata dopo la distribuzione delle regole complete del sensore auditd (cve-dirty-frag.rules). La catena ha correlato vmsplice() + splice() dal pid=5670 (exe=/home/kr/exp) entro la finestra di 120 secondi. Questo è il segnale di massima confidenza nel set di rilevamento.

Policy SCA - Punteggio 50% (baseline senza sensore distribuito)

Il punteggio 50% rappresenta un sistema baseline pulito con i moduli vulnerabili assenti (non caricati) ma senza lo stack di rilevamento e hardening distribuito. Questo è il punto di partenza previsto per un sistema che non ha ancora applicato le misure di remediation di questo repository.

wazuh-analysisd -t: exit 0 - zero avvisi - tutte e 9 le regole caricate.

Nota Ubuntu 24.04 - AppArmor e fallback della variante

Ubuntu 24.04 include apparmor_restrict_unprivileged_userns=1 per impostazione predefinita (kernel 6.1+). Questa impostazione limita unshare(CLONE_NEWUSER) per i processi non privilegiati, il che mitiga parzialmente la variante ESP (CVE-2026-43284). Il kernel registra un evento AppArmor AUDIT per il tentativo, ed è questo che attiva la regola 200002 nel nostro laboratorio.

Il binario dell'exploit ricade automaticamente sulla variante RxRPC (CVE-2026-43500) quando il percorso ESP fallisce. La variante RxRPC non richiede CLONE_NEWUSER e aggira questa restrizione.```bash

Check if your Ubuntu system has this restriction active

cat /proc/sys/kernel/apparmor_restrict_unprivileged_userns

1 = restricted (ESP variant blocked, RxRPC still active)

0 = not restricted (both variants active)

Rules 200000/200001 (vmsplice/splice) rimangono attive e pertinenti per:
- Ubuntu 22.04 e versioni precedenti
- Debian 11/12
- RHEL 8/9
- Qualsiasi kernel con `apparmor_restrict_unprivileged_userns=0`

La copertura completa delle regole 9/9 è stata validata tramite `wazuh-logtest` su Wazuh 4.14.4.

---

## Rimedio

### Mitigazione immediata (prima della patch del kernel)

**Per la variante RxRPC (CVE-2026-43500):**```bash
echo 'install rxrpc /bin/false' >> /etc/modprobe.d/dirty-frag.conf
rmmod rxrpc 2>/dev/null || true

Sicuro su tutti i sistemi non-AFS. Non influisce su IPsec, kTLS, SSH o sullo stack di rete generale.

Per la variante ESP (CVE-2026-43284) - solo se non sono in uso tunnel IPsec:```bash echo 'install esp4 /bin/false' >> /etc/modprobe.d/dirty-frag.conf echo 'install esp6 /bin/false' >> /etc/modprobe.d/dirty-frag.conf rmmod esp4 esp6 2>/dev/null || true

> **ATTENZIONE:** Mettere in blacklist `esp4`/`esp6` interrompe i tunnel IPsec strongSwan/Libreswan. Non applicare su host con connessioni IPsec attive.

### Correzione permanente

Applica il commit del kernel `f4c50a4034e6` tramite l'aggiornamento del kernel della tua distribuzione.```bash
# Ubuntu / Debian
apt update && apt upgrade linux-generic

# RHEL / Amazon Linux
dnf update kernel

# SUSE
zypper update kernel-default

Relazione con Copy Fail (CVE-2026-31431)

Entrambe le vulnerabilità sfruttano lo stesso sink di decrittazione authencesn nel kernel Linux per scrivere byte controllati dall'attaccante nella page cache. La differenza sta nel modo in cui raggiungono tale sink.

Entrambi i set di regole possono coesistere in sicurezza sullo stesso manager Wazuh. I namespace delle chiavi auditd sono separati e non ci sono conflitti tra gli ID delle regole.

Cronologia della divulgazione

Riepilogo della policy SCA

Regole di rilevamento, configurazione del sensore auditd e policy SCA validate su Wazuh 4.14.4, Ubuntu 24.04.2 LTS (kernel 6.8.0-111-generic).

Autore

Kislley Rodrigues (m0us3r) Ambasciatore Wazuh | Ingegneria del rilevamento | Blue Team

Ringraziamenti

• V4bel per la scoperta, la divulgazione pubblica e il PoC di CVE-2026-43284 / CVE-2026-43500 - https://github.com/V4bel/dirtyfrag
• Wazuh Team per la piattaforma SIEM/XDR open source
• Anthony Faruna e Katia Bukcovac - Wazuh Ambassador Program, per la revisione e i feedback su questo deliverable di rilevamento
• CloudLinux per il riferimento alla mitigazione tempestiva disponibile su https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update

Wazuh

Questo progetto è stato sviluppato nell'ambito del Wazuh Ambassador Program.

Wazuh è una piattaforma di sicurezza gratuita e open source che fornisce protezione XDR e SIEM unificata. Scopri di più su wazuh.com.