Május 13-án javították a sebezhetőséget a népszerű nginx webszerverben, amelyet leterhelt rendszerek esetében használnak: CVE-2026-42945, amely potenciálisan RCE-hez vezethet. A sebezhetőség 18 évvel ezelőtt (2008) tűnt fel a 0.6.27-es verzióban.
A kihasználásához a szerver konfigurációjában egy bizonyos direktívakombinációra van szükség, ami nem kötelező, de előfordulhat, például a következő:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Fontos részletek:
- először a rewrite direktíva következik, ahol (az első argumentum) a mintázatban kiemelt paraméter (valami zárójelben) helyettesítve van (a második argumentumnak) egy kérdőjelet tartalmazó úttal;
- a set direktíva (helyette a második rewrite vagy if is megfelel), amely a kiemelt paramétert használja az átkonfigurált útról (ebben az esetben ez $1).
A sebezhetőség úgy működik:
- az első rewrite direktíva, amikor a kérdőjelbe ütközik, beállít egy belső is_args zászlót, ami azt jelenti, hogy "most gyűjtjük a GET paramétereket a módosított URL-hez, mindent escape-elni kell", és (ez a hiba lényege), elfelejti ezt a zászlót visszaállítani a működése végén;
- a következő set direktíva a $myvar értékének létrehozásakor tévesen alkalmazza a korábban beállított is_args-t, és escape-elt értéket jegyez a my_var-ban a kiemelt paraméterből $1; a probléma az, hogy a $myvar számára a puffert korábban allokálják, még a helyettesítések előtt, és a hossza is_args=0-ra van kiszámítva, tehát az escape-elt érték hosszabb lesz, mint a kijelölt puffer, amely miatt az írás a kijelölt pufferen kívül más adatstruktúrákba történik. Ehhez elegendő, ha egy olyan kérdést küldünk, amely escape-elésre szoruló karaktereket tartalmaz, például a „plusz” jeleket, a reguláris kifejezés kiemelt paraméterében.
Ha a hoszton nincs ASLR, akkor ez a sebezhetőség kihasználható távoli kódvégrehajtásra az nginx munkafolyamatának jogosultságaival, van PoC (ott nem tiszta exploit, demó a homokozóban).
A sebezhetőséget a nginx 1.30.1 stabil ágon, valamint az új fejlesztési 1.31.0 verzióban javították. link a commithoz.
Figyelemre méltó, hogy 14 évvel ezelőtt (2012) hasonló hiba már javításra került egy másik helyen a közelben. máshol, a közelben.
——-
Az F5 weboldalán ajánlás található a sebezhetőség ideiglenes semlegesítésére, amennyiben nem lehetséges gyorsan frissíteni az nginx verziót – a névtelen paramétereket névlegesen kell átírni, és ezzel az ő állításuk szerint a sebezhetőség nem fog jelentkezni. Példa onnan:
korábban: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
az új: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
A sebezhetőségről Zhenpeng (Leo) Lin a DepthFirst-től nyújtott információt. Ezen kívül ő jelezte az alábbi problémákat, amelyek szintén javítva lettek:
- CVE-2026-40701 (commit-ra.) use-after-free ssl_verify_client+ssl_ocsp használata közben (látszólag RCE nélkül)
- CVE-2026-42934 (commit-ra.) buffer túlcsordulás az utf-8 parserben specifikus körülmények között, ami kis adatkiáramlást vagy a munkafolyamat összeomlását okozhatja
- CVE-2026-42946 (commit-ra.) túlzott memóriaallokáció és buffer túlcsordulás scgi/uwsgi modulok használatakor, a probléma megjelenik, ha rosszindulatú háttér (upstream) van az említett protokollokon, vagy mitm támadás során a háttér kommunikációjával, ami nginx memóriájának olvasását vagy a munkafolyamat összeomlását eredményezheti
Forrás: linux.org.ru
