TL; DREfter at have stødt på det tredje bufferoverløb, der blev opdaget i 2026 (og ifølge F5 en RCE, hvis der ikke er nogen ASLR), mens han arbejdede med regexps og variabler, besluttede freenginx-udvikleren Maxim Dunin, at det var tid til at stoppe det og tilføjede en variabelstørrelseskontrol til sit produkt, før han skrev data til det. Nginx har siden kopieret denne funktion, hvilket giver håb om, at nye CVE'er relateret til dette problem vil blive elimineret.
Nu til detaljerne.
19. juni blev lavet begå i Freenginx, som tilføjer et slutfelt til variabelbeskrivelsen, der angiver slutningen af bufferen. Tidligere var der kun en pointer til dens begyndelse (pos), den nødvendige længde blev (og bliver stadig) beregnet på forhånd, og når dataene blev kopieret til variablen, blev det antaget, at den korrekt beregnede længde ville garantere, at dataene ville passe ind i bufferen. Desværre har dette allerede vist sig at være forkert to gange i maj 2026 på grund af forskellige forglemmelser.1 (linux.org.ru), 2 (linux.org.ru)), hvilket førte til bufferoverløb og alvorlige konsekvenser. Når en variabels buffer oprettes, fyldes pointeren til dens slutning også, og før data skrives til variablen, vil anmodningsbehandlingen afsluttes med en fejl på en kontrolleret måde, hvis dataene ikke passer. Det betyder, at længdeberegningsfejl stadig kan forekomme, men de spilder ikke hukommelse; de vil kun fejle den specifikke HTTP-anmodning. Følgende commits (2 (freenginx.org), 3 (freenginx.org)) lignende beskyttelse blev tilføjet til andre dele af koden, herunder adgangslogningskoden. En version blev offentliggjort den 7. juli Freenginx 1.31.3, som inkluderer denne rettelse.
Den 15. juli blev disse commits hentet af nginx (1 (github.com), 2 (github.com), 3 (github.com)(af en eller anden grund byttede man om på den anden og tredje i kæden), blev problemet tildelt CVE-2026-42533, og F5 udgav en officiel SA (f5.com).
Angående den specifikke sårbarhed denne gang: den manifesterer sig, når map-direktivet bruges med regexps med udtrukne parametre. Med hensyn til de andre betingelser, der kræves for at den kan udløses, adskiller teksten i commit-beskrivelsen sig en smule fra teksten i SA'en: SA'en angiver, at en bestemt streng skal beregnes derefter, som bruger den udtrukne parameter, der er tilbage fra kortet, før resultatet af det samme kort. I commit-beskrivelsen i eksemplet er variablen, der indeholder den udtrukne parameter, også nullet ud mellem disse trin. Uanset hvad, er det usandsynligt, at dette forekommer i de fleste kørende nginx'er, og derfor påvirkede sårbarheden kun få personer. Det er også værd at bemærke, at en rettelse til længdeberegningen specifikt til dette tilfælde ikke er i de committede redigeringer (eller søgte jeg dårligt?), der er kun en beskyttelse, der forvandler problemet til en kontrolleret HTTP-anmodningsfejl. Selvom nogle rettelser blev tilføjet til freenginx den 19. juli (5bfb, 7622, b906) beregning af længden for en lignende situation, men det er ikke umiddelbart klart, om dette er tilfældet eller ej.
Sårbarheden opstod i version 0.9.6 af nginx, og rettelser blev inkluderet i versionerne freenginx 1.31.3, nginx 1.30.4 og nginx 1.31.3.
Nginx SA takker en række personer for uafhængigt at have rapporteret sårbarheden og overholdt "koordinerede oplysningsstandarder":
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 gjort os opmærksomme på dette problem 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 commit-meddelelsen. changelogDenne rettelse er ikke engang mærket som "sikkerhed" eller "fejlrettelse", kun "funktion". Tilsyneladende anså forfatteren ikke dette problem for at være kritisk. Det er umuligt at fastslå forholdet mellem de rapporterede problemer af de førnævnte personer i F5 og commit'en kopieret fra freenginx, eller om de (eller andre) rapporterede problemet til forfatteren af freenginx.
Kilde: linux.org.ru
