Op 13 mei is een kwetsbaarheid in de populaire webserver nginx, gebruikt voor zwaar beladen systemen, verholpen: CVE-2026-42945, die mogelijk kan leiden tot RCE. De kwetsbaarheid is 18 jaar (2008) geleden ontstaan in versie 0.6.27.
Voor de exploitatie ervan moet er een specifieke combinatie van directieven in de serverconfiguratie zijn, niet dat ze voor iedereen aanwezig is, maar soms komt het voor, bijvoorbeeld zo:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Belangrijke details:
- eerst komt de rewrite-directive, waarbij (de eerste argument) de reguliere expressie met het geƫxtraheerde parameter (iets in haakjes) wordt vervangen door (het tweede argument) een pad dat een vraagteken bevat;
- de set-directive (in plaats daarvan kan ook een tweede rewrite of if worden gebruikt), die de geƫxtraheerde parameter uit het oorspronkelijk herschreven pad gebruikt (in dit geval is dat $1).
De kwetsbaarheid werkt als volgt:
- de eerste rewrite-directive stelt, wanneer deze het vraagteken tegenkomt, de interne vlag is_args in, wat betekent "we zijn nu parameters aan het verzamelen voor de vervangende url, alles moet geescaped worden", en (dit is de kern van de bug) vergeet deze vlag aan het einde van zijn uitvoering terug te zetten;
- de daaropvolgende set-directive past ten onrechte de eerder ingestelde is_args toe bij het genereren van de waarde voor $myvar, en schrijft de geescape waarde van de geƫxtraheerde parameter $1 in my_var; het probleem is dat de buffer voor $myvar al eerder wordt toegewezen, nog voor de vervangingen worden uitgevoerd, en de lengte ervan wordt berekend met is_args=0, wat betekent dat de geescape waarde langer is dan de toegewezen buffer, waardoor de schrijfactie buiten de toegewezen buffer in andere gegevensstructuren van de server plaatsvindt. Om dit te laten gebeuren, is het voldoende om een verzoek te sturen met symbolen die geescaped moeten worden, zoals plus-tekens, op de plaats waar de parameter van de reguliere expressie wordt geƫxtraheerd.
Als er op de host geen ALSR is, kan deze kwetsbaarheid worden geƫxploiteerd voor het op afstand uitvoeren van code met de rechten van het nginx-proces, er is PoC (er is geen exploit in pure zin, het is een demonstratie in een sandbox).
De kwetsbaarheid is verholpen in de stabiele tak van nginx 1.30.1, en in de nieuwe ontwikkeltak 1.31.0. link naar de commit.
Opmerkelijk is dat 14 jaar geleden (2012) een soortgelijke fout al was verholpen op een andere plek dichtbij.
āā-
Op de F5-website is er een aanbeveling voor tijdelijke neutralisatie van de kwetsbaarheid voor het geval het niet mogelijk is om snel de nginx-versie bij te werken - men moet niet-genaamde parameters vervangen door genaamde, en in dat geval zou de kwetsbaarheid volgens hen niet optreden. Voorbeeld daaruit:
was: rewrite ^\/users\/([0-9]+)\/profile\/(.*)$ \/profile.php?id=$1&tab=$2 last;
is geworden: rewrite ^\/users\/(?<user_id>[0-9]+)\/profile\/(?<section>.*)$ \/profile.php?id=$user_id&tab=$section last;
Informatie over de kwetsbaarheid werd verstrekt door Zhenpeng (Leo) Lin van DepthFirst. Daarnaast meldde hij de volgende problemen, die ook zijn opgelost:
- CVE-2026-40701 (commit) use-after-free bij gebruik van ssl_verify_client+ssl_ocsp (blijkbaar zonder RCE)
- CVE-2026-42934 (commit) lezen buiten de buffer in de utf-8-parser onder specifieke omstandigheden, kan leiden tot een kleine gegevenslek of een crash van het werkproces
- CVE-2026-42946 (commit) overmatige geheugentoewijzing en lezen buiten de buffer bij gebruik van scgi/uwsgi-modules, het probleem doet zich voor bij een kwaadaardige backend (upstream) via de genoemde protocollen, of bij een MITM-aanval op de communicatie met de backend, kan leiden tot het lezen van geheugen van nginx of een crash van het werkproces
Bron: linux.org.ru
