TL;DR: Affrontando il terzo overflow del buffer scoperto nel 2026 (e, secondo F5, RCE se non c'è ASLR) durante l'uso di espressioni regolari e variabili, lo sviluppatore di freenginx Maxim Dunin ha deciso che era giunto il momento di porre fine a questa situazione e ha aggiunto al suo prodotto un controllo della dimensione della variabile prima di scriverci i dati. Questa novità è stata successivamente adottata anche da nginx, il che offre speranza per la cessazione di nuove CVE su questo argomento.
Ora i dettagli.
Il 19 giugno è stato fatto commit in freenginx, aggiungendo nel descrittore della variabile un campo end, che indica la fine del buffer. In precedenza c'era solo un puntatore all'inizio (pos), mentre la lunghezza necessaria veniva calcolata (e ora viene calcolata) in anticipo, e al momento della copia dei dati nella variabile si presumeva che la lunghezza calcolata in precedenza garantisse che i dati entrassero nel buffer. Sfortunatamente, già due volte a maggio 2026 a causa di diverse omissioni questo non si è verificato (1 (linux.org.ru), 2 (linux.org.ru)), il che ha portato a overflow del buffer e conseguenze sfavorevoli. Ora, al momento della creazione del buffer della variabile, viene riempito anche il puntatore alla sua fine e prima di scrivere i dati nella variabile, se i dati non ci stanno, l'elaborazione della richiesta terminerà in modo controllato con un errore. Ciò significa che gli errori di calcolo della lunghezza potrebbero persistere, ma ora non danneggeranno la memoria, ma falliranno solo una specifica richiesta http. I commit successivi (2 (freenginx.org), 3 (freenginx.org)) hanno aggiunto una protezione analoga in altre parti del codice, incluso il codice di gestione del log di accesso. Il 7 luglio è stata pubblicata la versione freenginx 1.31.3, che includeva questa correzione.
Il 15 luglio questi commit sono stati adottati da nginx (1 (github.com), 2 (github.com), 3 (github.com), per qualche motivo invertendo il secondo e il terzo nella catena), al problema è stato assegnato CVE-2026-42533, e F5 ha rilasciato un ufficiale SA (f5.com).
Riguardo a una specifica vulnerabilità stavolta: si manifesta durante l'uso della direttiva map con regex e parametri evidenziati. A proposito delle altre condizioni necessarie per il suo attivarsi, il testo nella descrizione del commit e il testo in SA differiscono leggermente: in SA si indica che successivamente dovrebbe esserci il calcolo di una certa stringa che utilizza il parametro evidenziato rimasto da map, prima del risultato di questo stesso map. Nella descrizione del commit, nell'esempio tra questi passaggi è coinvolta anche la resettazione di una variabile contenente il parametro evidenziato. Ad ogni modo, nella maggior parte degli nginx avviati è probabile che tale cosa non venga riscontrata e la vulnerabilità in tal modo ha interessato pochi. È anche importante notare che non sembra esserci una correzione del calcolo della lunghezza specificamente in questo caso nelle modifiche commit, c'è solo una protezione che trasforma il problema in un fallimento controllato della richiesta http. Anche se il 19 luglio in freenginx sono stati aggiunti alcuni correttivi (5bfb, 7622, b906) al calcolo della lunghezza per una situazione simile, ma non è chiaro al volo se sia o meno.
La vulnerabilità è apparsa nella versione nginx 0.9.6, le correzioni sono state incluse nelle versioni freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
In SA nginx sono espressi ringraziamenti a diverse persone per aver segnalato in modo indipendente la vulnerabilità e per aver rispettato «gli standard di divulgazione coordinata»:
F5 riconosce Ming Xuan, DKD (@pidifn), Ji’an Zhou e Zhen Yan di AntAISecurityLab, Rafael Gacek, Sergii Negodiuk di EVO.company, Lam Jun Rong di Calif.io, Mufeed VH di Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin di depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin di Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) e Milan Jovic (Kljunowsky) per aver portato questa questione alla nostra attenzione in modo indipendente e per aver seguito i massimi standard di divulgazione coordinata.
In freenginx le informazioni associate alla correzione si limitano fondamentalmente a un messaggio nel commit. In changelognon è nemmeno contrassegnata con le etichette «sicurezza» (security) o «correzione» (bugfix), ma semplicemente «aggiunta» (feature). È probabile che l'autore non considerasse questo problema critico. Come si relazionano le segnalazioni del problema da parte delle persone nominate in F5 con il commit preso da freenginx, se hanno informato (o qualcun altro) l'autore di freenginx riguardo al problema, non è riuscito a scoprirlo.
Fonte: linux.org.ru
