TL;DR: Affrontando il terzo overflow di buffer scoperto nel 2026 (e, secondo F5, RCE se non c'è ASLR) durante l’utilizzo di regex e variabili, lo sviluppatore di freenginx, Maksim Dunin, ha deciso che era ora di fermarsi, e ha aggiunto al suo prodotto un controllo della dimensione della variabile prima di scriverci dati. Da lì, questa novità è stata portata anche in nginx, il che dà speranza a una cessazione di nuovi CVE su questo tema.
Ora i dettagli.
Il 19 giugno è stata implementata commit in freenginx, che aggiunge nel descrittore della variabile un campo end, che indica la fine del buffer. In precedenza c'era solo un puntatore all'inizio (pos), la lunghezza necessaria veniva calcolata (e viene ancora calcolata) in anticipo, e al momento della copia dei dati nella variabile si presumeva che la lunghezza precedentemente calcolata garantisse che i dati potessero entrare nel buffer. Sfortunatamente, due volte a maggio 2026 a causa di varie omissioni, questo non si è rivelato vero (1 (linux.org.ru), 2 (linux.org.ru)), il che ha comportato overflow di buffer e gravi conseguenze. Ora, quindi, quando si crea un buffer, viene memorizzato anche il puntatore alla sua fine, e prima di scrivere dati nella variabile, se i dati non ci entrano, l'elaborazione della richiesta sarà controllatamente terminata con un errore. Ciò significa che gli errori di calcolo della lunghezza possono ancora esistere, ma ora non danneggeranno la memoria, ma falliranno solo una specifica richiesta http. Nei commit successivi (2 (freenginx.org), 3 (freenginx.org)) è stata aggiunta una protezione simile in altre parti del codice, incluso il codice di gestione del registro di accesso. Il 7 luglio è stata rilasciata la versione freenginx 1.31.3, che include questa correzione.
Il 15 luglio questi commit sono stati traslati in nginx (1 (github.com), 2 (github.com), 3 (github.com), cambiando per qualche motivo l'ordine del secondo e del terzo nella catena), è stata assegnata alla problematica CVE-2026-42533, e F5 ha rilasciato un SA (f5.com).
Riguardo a una specifica vulnerabilità questa volta: si manifesta quando si utilizza la direttiva map con espressioni regolari che contengono parametri di cattura. Per quanto riguarda le altre condizioni necessarie affinché si attivi, il testo nella descrizione del commit e quello in SA presentano alcune divergenze: in SA è indicato che successivamente deve avvenire il calcolo di una certa stringa, che utilizza il parametro di cattura rimasto da map, prima del risultato di questo stesso map. Nella descrizione del commit, nell'esempio, tra questi passaggi c'è anche un azzeramento della variabile che contiene il parametro di cattura. Ad ogni modo, nella maggior parte delle istanze di nginx avviate, è probabile che non si incontri il problema e quindi la vulnerabilità ha colpito poche persone. Va inoltre notato che le correzioni sul calcolo della lunghezza in questo caso specifico nelle modifiche commesse sembrano non esserci (oppure ho cercato male?), c'è solo una protezione che trasforma il problema in un errore controllato della richiesta http. Anche se il 19 luglio in freenginx sono state aggiunte alcune correzioni (5bfb, 7622, b906) al calcolo della lunghezza per situazioni simili, non è possibile capire subito se si tratta di questo 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 stati espressi ringraziamenti a diverse persone per le segnalazioni indipendenti della vulnerabilità e per il rispetto degli "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 indipendentemente questa problematica alla nostra attenzione e per aver rispettato i più alti standard di divulgazione coordinata.
In freenginx, le informazioni aggiuntive sulla correzione sono effettivamente limitate a un messaggio nel commit. In changelog- non è nemmeno etichettata con la dicitura "sicurezza" (security), né "correzione" (bugfix), ma semplicemente "aggiunta" (feature). Probabilmente, l'autore non ha considerato il problema critico. Non è stato possibile chiarire come le segnalazioni sul problema da parte delle persone indicate in F5 si rapportino al commit preso da freenginx e se abbiano informato (o qualcun altro) l'autore di freenginx riguardo al problema.
Fonte: linux.org.ru
