DIRTY FRAG Erkennung mit Wazuh 4.14.4 - CVE-2026-43284 / CVE-2026-43500

Erkennungsentwicklung für die Dirty Frag Kernel LPE - Ubuntu / RHEL / Debian / Amazon Linux

Was ist Dirty Frag?

CVE-2026-43284 / CVE-2026-43500 ist eine lokale Rechteausweitung (LPE) im Linux-Kernel, die zwei unabhängige Page-Cache-Schreibprimitive verknüpft, um Root von einem unprivilegierten Benutzerkonto aus zu erlangen. Eine einzelne kompilierte Binärdatei erlangt Root auf allen großen Linux-Distributionen. Keine Race-Condition. Kein Heap-Spray. Kein Kernel-Offset erforderlich.

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

We have source. We output translation.

Wenn CLONE_NEWUSER durch AppArmor blockiert wird (Ubuntu 24.04+ Standard), fällt der Exploit automatisch von der ESP-Variante auf die RxRPC-Variante zurück. Dieselbe Binärdatei erreicht in beiden Fällen Root.

KRITISCH: Die Copy Fail-Mitigation (Blacklisting von algif_aead) schützt nicht vor Dirty Frag. Beide Sicherheitslücken teilen denselben authencesn-Sink, aber Dirty Frag wird über einen völlig anderen Codepfad ausgelöst. Falls Sie die Copy Fail-Mitigation bereitgestellt haben, sind Sie weiterhin gefährdet.

Entdeckt und veröffentlicht von V4bel – https://github.com/V4bel/dirtyfrag

Offizielle Referenzen

Warum FIM versagt – Warum dieses Repository existiert

Dirty Frag schreibt direkt in den speicherinternen Page Cache. Die Binärdatei auf der Festplatte wird nie verändert. Der Kernel markiert die beschädigte Seite nie als „dirty“, daher wird der Writeback nie ausgeführt. Die Datei auf der Festplatte ist vor und nach der Ausnutzung byteweise identisch mit dem Original.``` 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

Die einzige effektive Erkennung ist verhaltensbasiert, durch Syscall-Überwachung auf Kernel-Ebene. Dieses Repository enthält produktionserprobte Wazuh-Regeln, die beide Exploit-Varianten auf Syscall-Ebene erkennen, unabhängig von Kernel-Version oder Patch-Status.

---

## Exploit-Kette```
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

Die Seitencache-Korruption ist die zentrale Grundlage beider Varianten. vmsplice pflanzt den vom Angreifer kontrollierten Protokoll-Header in eine Pipe. splice liefert die Seitencache-Seiten der Zieldatei in dieselbe Pipe ohne Kopieren. Wenn der Kernel den kombinierten Puffer durch den Entschlüsselungspfad verarbeitet, schreibt er die vom Angreifer kontrollierten Bytes in den Seitencache der Zieldatei.

Betroffene Systeme

Bestätigt durch @m0us3r - Ubuntu 24.04.2 LTS Testlabor

Bestätigt durch Autor (github.com/V4bel/dirtyfrag)

Alle Linux-Kernel seit 2017 sind betroffen. Die AppArmor unprivileged_userns-Einschränkung auf Ubuntu 24.04+ blockiert die ESP-Variante, aber die RxRPC-Variante umgeht sie vollständig.

CVE-2026-43284 (ESP): im Bereich von Commit cac2661c53f3 (2017-01-17) bis f4c50a4034e6 (2026-05-05) - GEFIXT im Hauptentwicklungszweig

CVE-2026-43500 (RxRPC): im Bereich von Commit 2dc334f1a63a (2023-06-08) bis upstream - NOCH KEIN PATCH VORHANDEN

Repository-Struktur```

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)

> **Hinweis zu local_rules.xml:** Die Regeln werden in `local_rules.xml` ausgeliefert, der Standarddatei für benutzerdefinierte Regeln in Wazuh unter `/var/ossec/etc/rules/local_rules.xml`. Falls Sie Ihre Erkennungsregeln lieber nach CVE organisiert halten möchten, können Sie den Inhalt als eigenständige Datei (z. B. `cve-2026-43284_rules.xml`) im selben Verzeichnis bereitstellen. Beide Ansätze funktionieren gleichermaßen.

---

## Erkennungsarchitektur

Zwei unabhängige Schichten – keine hängt von der Kernelversion oder dem Patch-Status ab.

### Schicht 1 – Verhaltenserkennung (auditd + Wazuh)

**Wichtiger Hinweis zu uid vs. auid:** Der Kindprozess der ESP-Variante ruft `unshare(CLONE_NEWUSER)` auf und mappt sich innerhalb des neuen Benutzernamespaces selbst als `uid=0`. Das Linux-Audit-Subsystem zeichnet in SYSCALL-Ereignissen die namespace-lokale uid auf, weshalb `-F uid!=0`-Filter die `vmsplice`- und `splice`-Ereignisse des Exploit-Kindprozesses nicht erfassen. `auid` (Audit-UID/Login-UID) wird bei der Anmeldung gesetzt und ändert sich durch Namespace-Remapping nicht. Die Sensorregeln für `vmsplice` und `splice` verwenden `-F auid>=1000`, um den tatsächlichen Login-Benutzer korrekt zu erfassen, unabhängig davon, was der Exploit innerhalb eines Namespaces tut.

**Auditd-Sensorregeln** (`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

Layer 2 - Vulnerability Surface (SCA Policy)

Automatische Konfigurationsprüfungen via sca/cve-dirty-frag.yml. Läuft alle 12 Stunden auf allen registrierten Agenten. Keine Kernel-Versionsprüfung erforderlich.

Regelketten-Architektur

Hinweis zur Entwicklung: Die Kettenregeln (200007/200008) werden ausgelöst, wenn zwei Signale vom selben Prozess innerhalb von 120 Sekunden eintreffen. vmsplice gefolgt von splice von derselben PID ist die Kern-Pipe-Einschleussequenz beider Varianten. AF_RXRPC-Socket gefolgt von splice von derselben PID ist spezifisch für den RxRPC-Pfad. Beide Ketten werden via wazuh-logtest mit 9/9 bestanden validiert.

Wazuh Dashboard - Bereitgestellte Regeln

Regeln 200000-200008 bereitgestellt und aktiv. Compliance-Tags: PCI_DSS, HIPAA, GDPR, NIST_800_53, MITRE ATT&CK. Regeln 200007 und 200008 erreichen Stufe 15 (Kritisch) bei korrelierter Kettenerkennung.

Bereitstellung

Schritt 1 - auditd installieren```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

### Schritt 2 - Bereitstellen von auditd Sensorregeln```bash
cp auditd/cve-dirty-frag.rules /etc/audit/rules.d/
augenrules --load
auditctl -l | grep dirty_frag

Erwartete Ausgabe (9 Regeln geladen):``` -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

### Schritt 3 - Wazuh-Erkennungsregeln bereitstellen

Fügen Sie den Inhalt von `rules/local_rules.xml` zu Ihrer vorhandenen `/var/ossec/etc/rules/local_rules.xml` hinzu, oder stellen Sie als eigenständige Datei bereit, wenn Sie die Regeln lieber nach CVE organisiert halten möchten:```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

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

### Schritt 4 - SCA-Richtlinie bereitstellen```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

Fügen Sie zur Agentengruppenkonfiguration hinzu (/var/ossec/etc/shared/default/agent.conf):```xml <agent_config> /var/ossec/etc/shared/cve-dirty-frag.yml </agent_config>

> **Erforderlich:** Die Remote-Befehlsausführung muss auf jedem Agenten aktiviert sein, damit die Prüfungen `c:lsmod` und `c:systemctl` ausgeführt werden können:
>
> ```bash
> echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
> systemctl restart wazuh-agent
> ``````bash
systemctl restart wazuh-manager

Schritt 5 - ossec.conf localfile konfigurieren

Stellen Sie sicher, dass der Wazuh-Agent das auditd-Protokoll aufnimmt. Fügen Sie innerhalb von <ossec_config> in /var/ossec/etc/ossec.conf auf jedem überwachten Host hinzu, oder verteilen Sie es über agent.conf:```xml <log_format>audit</log_format> /var/log/audit/audit.log

---

## Validierung

### wazuh-logtest - alle 9 Regeln```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"

Erwartet für den Kettentest:``` id: '200000' level: '10' <- vmsplice signal id: '200007' level: '15' <- CHAIN ESP confirmed - IMMEDIATE INVESTIGATION REQUIRED

### Überprüfen, ob auditd Ereignisse nach der Exploit-Ausführung erfasst hat```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

Überprüfen der von Wazuh generierten Alarme```bash

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

Erwarteter SCA-Score (Basissystem ohne Sensor oder auditd bereitgestellt): **50%** (3 bestanden / 3 fehlgeschlagen).

---

## Produktionsvalidierungsnachweise

### Exploit-Ausführung - Agent 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

Benutzer kr (uid=1000) ohne Privilegien führte die PoC-Binärdatei aus und erlangte eine Root-Shell (uid=0). Wazuh erfasste und alarmierte in Echtzeit.

Erster Validierungslauf - 8. Mai 2026 (52 Treffer)

Kontext: Dieser Lauf wurde ausgeführt, bevor die vollständigen auditd-Sensorregeln bereitgestellt wurden. Die Regeln 200002, 200005 und 200006 wurden über die Basis-auditd-Abdeckung ausgelöst. Die vollständige Kettenregel (200007) erfordert, dass die Sensordatei cve-dirty-frag.rules aktiv ist - siehe den vollständigen Validierungslauf unten.

Vollständiger Validierungslauf - Kettenregel 200007 ausgelöst (15. Mai 2026)

Regel 200007 wurde ausgelöst, nachdem die vollständigen auditd-Sensorregeln (cve-dirty-frag.rules) bereitgestellt wurden. Die Kette korrelierte vmsplice() + splice() von pid=5670 (exe=/home/kr/exp) innerhalb des 120-Sekunden-Fensters. Dies ist das Signal mit der höchsten Vertrauenswürdigkeit im Erkennungssatz.

SCA-Richtlinie - Bewertung 50% (Basislinie ohne bereitgestellten Sensor)

Die Bewertung von 50% repräsentiert ein sauberes Basissystem, bei dem die anfälligen Module nicht vorhanden (entladen) sind, jedoch ohne den bereitgestellten Erkennungs- und Härtungsstapel. Dies ist der erwartete Ausgangspunkt für ein System, das die in diesem Repository beschriebenen Abhilfemaßnahmen noch nicht angewendet hat.

wazuh-analysisd -t: exit 0 - null Warnungen - alle 9 Regeln geladen.

Hinweis zu Ubuntu 24.04 - AppArmor und Varianten-Rückfall

Ubuntu 24.04 wird standardmäßig mit apparmor_restrict_unprivileged_userns=1 ausgeliefert (Kernel 6.1+). Diese Einstellung schränkt unshare(CLONE_NEWUSER) für unprivilegierte Prozesse ein, was die ESP-Variante (CVE-2026-43284) teilweise entschärft. Der Kernel protokolliert ein AppArmor AUDIT-Ereignis für den Versuch, was in unserem Labor die Regel 200002 auslöst.

Die Exploit-Binärdatei fällt automatisch auf die RxRPC-Variante (CVE-2026-43500) zurück, wenn der ESP-Pfad fehlschlägt. Die RxRPC-Variante benötigt kein CLONE_NEWUSER und umgeht diese Einschränkung.```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)

Regeln 200000/200001 (vmsplice/splice) bleiben aktiv und relevant für:
- Ubuntu 22.04 und früher
- Debian 11/12
- RHEL 8/9
- Jeder Kernel mit `apparmor_restrict_unprivileged_userns=0`

Die vollständige 9/9-Regelabdeckung wurde mittels `wazuh-logtest` auf Wazuh 4.14.4 validiert.

---

## Abhilfe

### Sofortige Abhilfe (vor Kernel-Patch)

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

Sicher auf allen Nicht-AFS-Systemen. Beeinträchtigt nicht IPsec, kTLS, SSH oder den allgemeinen Netzwerk-Stack.

Für die ESP-Variante (CVE-2026-43284) - nur wenn keine IPsec-Tunnel verwendet werden:```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

> **WARNUNG:** Blacklisting von `esp4`/`esp6` unterbricht strongSwan/Libreswan-IPsec-Tunnel. Nicht auf Hosts anwenden, die aktive IPsec-Verbindungen ausführen.

### Dauerhafte Behebung

Wenden Sie den Kernel-Commit `f4c50a4034e6` über Ihr Distributionskernel-Update an.```bash
# Ubuntu / Debian
apt update && apt upgrade linux-generic

# RHEL / Amazon Linux
dnf update kernel

# SUSE
zypper update kernel-default

Beziehung zu Copy Fail (CVE-2026-31431)

Beide Schwachstellen nutzen denselben authencesn-Decrypt-Sink im Linux-Kernel, um vom Angreifer kontrollierte Bytes in den Page-Cache zu schreiben. Der Unterschied liegt darin, wie sie diesen Sink erreichen.

Beide Regelsätze können sicher auf demselben Wazuh-Manager koexistieren. Die Auditd-Schlüssel-Namensräume sind getrennt und es gibt keine Regel-ID-Konflikte.

Offenlegungszeitplan

SCA-Richtlinienübersicht

Erkennungsregeln, Auditd-Sensorkonfiguration und SCA-Richtlinie validiert auf Wazuh 4.14.4, Ubuntu 24.04.2 LTS (Kernel 6.8.0-111-generic).

Autor

Kislley Rodrigues (m0us3r) Wazuh-Botschafter | Erkennungstechnik | Blue Team

Danksagungen

• V4bel für die Entdeckung, öffentliche Offenlegung und den PoC von CVE-2026-43284 / CVE-2026-43500 - https://github.com/V4bel/dirtyfrag
• Wazuh-Team für die offene SIEM/XDR-Plattform
• Anthony Faruna und Katia Bukcovac - Wazuh-Botschafterprogramm, für die Überprüfung und das Feedback zu diesem Erkennungsergebnis
• CloudLinux für die frühe Abhilfemaßnahmen-Referenz unter https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update

Wazuh

Dieses Projekt wurde im Rahmen des Wazuh-Botschafterprogramms entwickelt.

Wazuh ist eine kostenlose Open-Source-Sicherheitsplattform, die vereinheitlichten XDR- und SIEM-Schutz bietet. Erfahren Sie mehr unter wazuh.com.