Quando JavaScript di NGINX si trasforma in una trappola di corruzione della memoria

All'estremità di uno stack web, piccole scelte di configurazione possono comportare rischi sproporzionati. Il layer JavaScript di NGINX, njs, è pensato per rendere più dinamica la gestione del traffico. Ma quando i dati derivati dalle richieste possono influenzare un percorso di proxy fetch, quella comodità può sconfinare nel territorio della sicurezza della memoria. L'attuale filone di avvisi indica un bug di gravità elevata nel modulo njs che può destabilizzare i server e, in condizioni specifiche, creare un esito molto più serio.

Fatti rapidi

• Il problema interessa l'estensione JavaScript di NGINX, non il core del web server in sé.
• Lo schema vulnerabile coinvolge js_fetch_proxy combinato con variabili NGINX controllate dal client.
• Gli aggressori remoti possono essere in grado di provocare crash in implementazioni esposte che usano la configurazione interessata.
• L'esecuzione di codice arbitrario può essere possibile in alcuni ambienti, a seconda delle protezioni della memoria e del percorso esatto di distribuzione.
• Il confine patchato conta: njs 0.9.9 e versioni successive sono descritte come corrette nelle indicazioni del vendor.

Perché questo bug di configurazione è importante

Il dettaglio importante non è semplicemente che NGINX abbia un bug. È dove si trova il bug: all'interno di un livello di configurazione eseguibile. NGINX njs consente agli operatori di eseguire JavaScript nei flussi di elaborazione delle richieste e ngx.fetch() può inviare richieste in uscita tramite un proxy impostato da js_fetch_proxy. Ciò significa che una funzionalità pensata per aggiungere flessibilità di routing può diventare una superficie di corruzione della memoria se valori controllati dalla richiesta vengono inseriti nell'URL del proxy.

Dal punto di vista difensivo, la condizione di attivazione è ciò che separa l'uso ordinario dall'esposizione. Se un'implementazione non carica mai njs, non chiama mai ngx.fetch() o mantiene le impostazioni del proxy statiche e fidate, il percorso di rischio pubblicato potrebbe non esistere. Se invece variabili provenienti da header, stringhe di query o cookie vengono interpolate nel percorso del proxy di fetch, l'applicazione inizia a fidarsi di dati influenzati dall'attaccante in un contesto runtime sensibile.

L'impatto pratico dipende dall'hardening dell'host. In alcune configurazioni, il risultato probabile è un crash del worker o riavvii ripetuti, il che conta comunque perché i reverse proxy sono in prima linea sulla disponibilità. In ambienti più deboli, un heap buffer overflow può essere più pericoloso, perché le lacune nelle protezioni della memoria possono lasciare spazio all'esecuzione di codice. Le informazioni disponibili supportano un'analisi del rischio, non un'affermazione definitiva che ogni server interessato si comporti allo stesso modo.

Al momento della stesura, le informazioni pubbliche non hanno ancora stabilito completamente la causa tecnica alla radice, la portata completa degli utenti interessati o se i sistemi downstream siano stati compromessi. Questa incertezza è uno dei motivi per cui i difensori dovrebbero concentrarsi sull'inventario delle versioni, sulla revisione della configurazione e sulla riduzione dell'esposizione, invece che soltanto sulle etichette di gravità nei titoli.

Cosa dovrebbero controllare ora i difensori

Gli amministratori dovrebbero cercare l'uso di njs nelle configurazioni NGINX, in particolare js_import, js_content, ngx.fetch() e qualsiasi impostazione js_fetch_proxy che incorpori variabili derivate dalla richiesta. Ove possibile, sostituire i valori dinamici del proxy con destinazioni statiche. Se njs non è necessario, rimuovere completamente quel percorso funzionale. Le mitigazioni dell'host come ASLR dovrebbero rimanere abilitate, perché i bug di sicurezza della memoria diventano più pericolosi quando tali protezioni mancano.

La lezione più ampia è semplice: il software edge moderno non è più soltanto configurazione statica. Una volta che la configurazione diventa programmabile, inizia a somigliare molto al codice - e il codice necessita dello stesso livello di scrutinio, disciplina nelle patch e consapevolezza dei confini di fiducia di qualsiasi altra superficie di attacco.

WIKICROOK

• modulo njs: Estensione JavaScript di NGINX usata per automatizzare l'elaborazione delle richieste HTTP e Stream.
• js_fetch_proxy: Una direttiva che imposta un proxy in avanti per le chiamate Fetch API e può includere variabili.
• Heap buffer overflow: Un bug di corruzione della memoria causato quando i dati scrivono oltre la fine di un buffer nell'heap.
• ASLR: Address Space Layout Randomization, una difesa che rende più difficile prevedere gli indirizzi di memoria.
• Esecuzione di codice arbitrario: La capacità di un attaccante di eseguire codice scelto su un sistema bersaglio dopo lo sfruttamento.

Conclusione: questo caso ricorda che i bug più pericolosi non si trovano sempre nei punti più rumorosi. Nel software infrastrutturale, una singola direttiva di scripting può creare un ponte tra i dati della richiesta e la memoria del processo. Le implementazioni più sicure sono quelle che trattano quel ponte come un punto di controllo, non come una comodità.