Laboratorio privato Nginx Rift ASLR, catena di exploit e registrazioni demo
Proof of concept di RCE per CVE-2026-42945, un overflow critico dell'heap buffer nel modulo ngx_http_rewrite_module di NGINX introdotto nel 2008. Il bug consente l'esecuzione di codice remoto non autenticato contro server che utilizzano le direttive rewrite e set.
Questo fork estende il PoC originale con una catena di bypass ASLR che combina l'overflow di NGINX con una primitiva comune di LFI/lettura arbitraria di file sullo stesso host. La primitiva di lettura file viene utilizzata per recuperare le mappe dei worker nginx, libc e /proc/<worker>/mem in tempo reale, quindi derivare l'indirizzo di system() e i target heap utilizzabili da remoto.
Versioni precedenti di questo lab causavano intenzionalmente il crash di un worker nginx per far scrivere al servizio un core dump, quindi recuperavano e analizzavano tale core dump tramite la primitiva di lettura file per ottenere lo stato del processo sensibile ad ASLR, inclusi i target heap. In questo repository, coreless è solo un'abbreviazione per "senza un core dump leggibile": il percorso predefinito corrente sostituisce questa dipendenza dal crash-core con letture di memoria procfs in tempo reale, mentre il percorso legacy core-guided conservato utilizza ancora il core dump generato dal worker.
Questa vulnerabilità — insieme ad altri tre problemi di corruzione della memoria (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — è stata scoperta autonomamente dal sistema di analisi della sicurezza di depthfirst dopo un singolo clic di onboarding del codice sorgente di NGINX.
Vuoi trovare problemi come questo nel tuo codice? Prova lo stesso sistema su https://depthfirst.com/open-defense.
Il motore di script di NGINX utilizza un processo a due passaggi: prima calcola la dimensione del buffer necessaria, poi copia i dati. Il flag is_args viene impostato sul motore principale quando una sostituzione di rewrite contiene ?, ma il passaggio di calcolo della lunghezza viene eseguito su un sotto-motore appena azzerato. Quindi:
is_args = 0 → restituisce la lunghezza grezza della cattura.is_args = 1 → chiama ngx_escape_uri con NGX_ESCAPE_ARGS, espandendo ogni byte escapabile a 3 byte.La copia sovrascrive il buffer heap sottodimensionato con dati URI controllati dall'attaccante. Lo sfruttamento utilizza il feng shui dell'heap tra richieste per corrompere il puntatore cleanup di un ngx_pool_t adiacente (spruzzato tramite corpi POST, poiché i byte URI non possono contenere byte nulli), reindirizzandolo a un falso ngx_pool_cleanup_s che invoca system() alla distruzione del pool.
Leggi di più su questo bug nel nostro articolo tecnico.
| Prodotto | Affetto | Corretto in |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |
| NGINX Plus | R32 – R36 | R36 P4, R35 P2, R32 P6 |
Avviso completo del fornitore: https://my.f5.com/manage/s/article/K000160932
Questo fork mantiene intatto il PoC di divulgazione originale, ma aggiunge un secondo percorso di ricerca focalizzato su una domanda più realistica:
Il bug può essere sfruttato contro una vera VM Linux x86_64 con ASLR abilitato, senza fare affidamento su offset Docker/lab hardcoded?
La risposta in questo fork di ricerca è sì, con importanti vincoli. Le catene funzionanti non disabilitano ASLR e non utilizzano gli indirizzi heap/libc hardcoded originali. Invece, derivano lo stato in esecuzione attraverso primitive accessibili via HTTP sulla stessa porta, quindi selezionano il target heap finale dai dati di divulgazione ottenuti da remoto.
Ci sono ora due percorsi di exploit con ASLR abilitato, con il percorso coreless trattato come il PoC corrente migliore:
nginx_rifter.py: il punto di ingresso pulito, autonomo, integrato per valutazione ed exploit. Il suo metodo di exploit predefinito è ora la catena coreless /proc/<nginx-worker>/mem.nginx_rifter_core_v2_1.py: la versione legacy preservata di nginx_rifter.py guidata dal core. È utile per riprodurre il vecchio percorso di ricerca VM testato con crash-core, ma non è più il PoC preferito.tools/proc_mem_coreless_exploit.py: il precedente harness di ricerca coreless autonomo. La sua logica è stata integrata in nginx_rifter.py; lo strumento rimane per la riproduzione di esperimenti grezzi.La topologia target è intenzionalmente sulla stessa porta:
/api/.../lfi.php?file=.../phpinfo.phpL'attuale percorso coreless proc-mem esegue i seguenti passaggi ad alto livello:
/proc/<pid>/maps del worker nginx e il file libc mappato.system() per quel worker./proc/<worker>/mem attraverso la primitiva di lettura file.Il percorso legacy core-guided esegue una derivazione simile degli indirizzi di base, poi causa intenzionalmente il crash di un worker, legge il file core generato tramite LFI e analizza quel core per individuare slot fake-cleanup spruzzati. Questo è stato un utile ponte di ricerca, ma dipende dalla politica di core-dump e dai permessi del filesystem che sono meno comuni nelle installazioni predefinite.
Questo non è lo stesso della demo Docker deterministica originale. Il percorso VM x86_64 lascia ASLR Linux normale abilitato e ricalcola gli indirizzi specifici del processo ad ogni esecuzione. Il percorso Docker coreless lascia anch'esso ASLR abilitato e rimuove il requisito insolito di un core leggibile, ma dipende dal comportamento dei permessi di procfs che deve essere verificato per la classe di target.
Questo fork è un laboratorio di ricerca controllato. Le catene con ASLR abilitato si basano su condizioni forti che non sono ipotesi di produzione universali:
/proc/<pid>/maps del worker nginx con lo stesso UID, il libc mappato e /proc/<pid>/mem a grandi offset mappati./proc/<pid>/maps del worker nginx con lo stesso UID, il libc mappato e il core del worker generato.