TL;DR: Stødt på den tredje buffer overflow, der blev opdaget i 2026 (og ifølge F5, RCE hvis der ikke er ASLR) ved arbejde med regex og variabler, besluttede udvikleren af freenginx, Maksim Dunin, at det var på tide at stoppe dette, og han tilføjede en kontrol af variabelstørrelsen, før der skrives data til den. Dette nytilkomne blev derefter taget over af nginx, hvilket giver håb om at stoppe nye CVE på dette område.
Her er detaljerne.
Den 19. juni blev der foretaget commit i freenginx, som tilføjer et felt 'end' til variabelbeskrivelsen, der angiver slutningen af bufferen. Tidligere var der kun en peger til begyndelsen (pos), den nødvendige længde blev beregnet (og beregnes stadig) på forhånd, og på tidspunktet for kopiering af data til variablen blev det antaget, at den korrekt beregnede længde tidligere ville sikre, at dataene passer ind i bufferet. Desværre har der to gange i maj 2026 været forskellige oversight, hvilket ikke har været tilfældet (1 (linux.org.ru), 2 (linux.org.ru)), hvilket førte til buffer overflow og dårlige konsekvenser. Så nu, når en buffers variabel oprettes, udfyldes pekeren til dens slutning, og før data skrives til variablen, hvis dataene ikke passer ind, vil behandlingen af anmodningen blive kontrolleret stoppet med en fejl. Det vil sige, beregningsfejlene kan fortsætte, men de vil nu ikke ramme hukommelsen, kun fejle den specifikke http-anmodning. Følgende commits (2 (freenginx.org), 3 (freenginx.org)) har tilføjet lignende beskyttelse til andre dele af koden, inklusive koden til at føre access-log. Den 7. juli blev version freenginx 1.31.3, der inkluderer denne rettelse, offentliggjort.
Den 15. juli blev disse commits overtaget af nginx (1 (github.com), 2 (github.com), 3 (github.com), af en eller anden grund byttede den pladsene på det andet og tredje i kæden), problemet fik tildelt CVE-2026-42533, og F5 udgav en officiel SA (f5.com).
Vedrørende den specifikke sårbarhed denne gang: den opstår ved brug af map-direktivet med regex'er med udtrukne parametre. Angående de øvrige nødvendige betingelser for, at den træder i kraft, varierer teksten i commitbeskrivelsen og teksten i SA en smule: det er angivet i SA, at der senere skal beregnes en bestemt streng, som bruger den udtrukne parameter fra map, før resultatet af selve map. I commitbeskrivelsen er der et eksempel, hvor der mellem disse trin også er nulstilling af variablen, der indeholder den udtrukne parameter. Under alle omstændigheder vil noget sådant sandsynligvis ikke blive mødt i de fleste kørte nginx'er, og sårbarheden har derved berørt få. Det er også værd at bemærke, at rettelserne til beregningen af længden specifikt i dette tilfælde ikke synes at være til stede i de committede ændringer (eller har jeg ikke søgt godt nok?), der er kun en beskyttelse, der gør problemet til en kontrolleret HTTP-anmodningsfejl. Selvom der den 19. juli blev tilføjet nogle rettelser i freenginx,5bfb, 7622, b906) til længde beregning for en lignende situation, men det er ikke klart, om det er tilfældet.
Sårbarheden opstod i version nginx 0.9.6, rettelserne kom ind i versionerne freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
I SA nginx nævnes tak til en række personer for uafhængige rapporter om sårbarheden og overholdelse af 'standarder for koordineret offentliggørelse':
F5 anerkender Ming Xuan, DKD (@pidifn), Ji’an Zhou, og Zhen Yan fra AntAISecurityLab, Rafael Gacek, Sergii Negodiuk fra EVO.company, Lam Jun Rong fra Calif.io, Mufeed VH fra Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin fra depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin fra Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil), og Milan Jovic (Kljunowsky) for uafhængigt at have bragt dette problem til vores opmærksomhed og for at følge de højeste standarder for koordineret offentliggørelse.
I freenginx er den ledsagende information om rettelsen faktisk begrænset til meddelelsen ved commit. I changelog-en er denne rettelse ikke engang mærket med 'sikkerhed' (security) eller 'fejlretning' (bugfix), kun 'tilføjelse' (feature). Sandsynligvis betragtede forfatteren ikke dette problem som kritisk. Hvordan meddelelserne om problemet fra de nævnte personer i F5 relaterer sig til den overtagne commit fra freenginx, og om de (eller andre) har rapporteret problemet til forfatteren af freenginx, har ikke været muligt at finde ud af.
Kilde: linux.org.ru
