13 maja została naprawiona luka w popularnym serwerze WWW nginx dla obciążonych systemów: CVE-2026-42945, która potencjalnie mogła doprowadzić do RCE. Luka ta pojawiła się 18 lat temu (2008 rok) w wersji 0.6.27.
Aby ją wykorzystać, w konfiguracji serwera musi być określona szczególna kombinacja dyrektyw, niekoniecznie obecna wszędzie, ale czasami występująca, na przykład taka:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Istotne szczegóły:
- najpierw występuje dyrektywa rewrite, gdzie (pierwszy argument) wyrażenie regularne z wydzielonym parametrem (coś w okrągłych nawiasach) jest zastępowane (drugim argumentem) ścieżką, która zawiera znak zapytania;
- dyrektywa set (zamiast niej również może być użyta druga dyrektywa rewrite lub if), która używa wydzielonego parametru z pierwotnej ścieżki po zapisie (w tym przypadku $1).
Luka działa w następujący sposób:
- pierwsza dyrektywa rewrite, napotykając znak zapytania, ustawia wewnętrzny flag is_args, co oznacza „teraz zbieramy parametry GET dla zastąpionego URL-a, trzeba wszystko ekraniiować”, i (w tym właśnie tkwi sedno błędu) zapomina zresetować ten flaga na końcu swojej pracy;
- kolejna dyrektywa set, przy formułowaniu wartości dla $myvar, błędnie stosuje wcześniej ustawiony is_args i zapisuje w my_var wartość z ekraniowanym parametrem $1; problem polega na tym, że bufor dla $myvar jest przydzielany wcześniej, jeszcze przed wykonaniem podstawień, a jego długość jest obliczana z is_args=0, to znaczy, że ekraniowana wartość okazuje się dłuższa niż przydzielony bufor, co powoduje zapis poza przydzielonym buforem do innych struktur danych serwera. Aby to się wydarzyło, wystarczy wysłać zapytanie z symbolami podlegającymi ekraniowaniu, na przykład znakami „plus”, w miejscu wydzielania parametru wyrażenia regularnego.
Jeśli na hoście nie ma ALSR, to ta luka może być wykorzystywana do zdalnego wykonania kodu z prawami procesu roboczego nginx, istnieje PoC (to nie jest eksploit w czystej postaci, tylko demonstracja w piaskownicy).
Luka została naprawiona w stabilnej wersji nginx 1.30.1 oraz w nowej wersji deweloperskiej 1.31.0. link do commita.
Zauważ, że 14 lat temu (2012 rok) podobny błąd już został naprawiony w innym miejscu w pobliżu.
——-
Na stronie F5 znajduje się zalecenie dotyczące tymczasowego zneutralizowania podatności w przypadku braku możliwości szybkiej aktualizacji wersji nginx – należy zastąpić parametry nienaudytowane na parametry nazwanne, a wtedy, według ich słów, podatność nie będzie się ujawniać. Przykład stamtąd:
było: rewrite ^\/users\/([0-9]+)\/profile\/(.*)$ \/profile.php?id=$1&tab=$2 last;
stało się: rewrite ^\/users\/(?<user_id>[0-9]+)\/profile\/(?<section>.*)$ \/profile.php?id=$user_id&tab=$section last;
Informacje o podatności zostały dostarczone przez Zhenpenge (Leo) Lina z DepthFirst. Ponadto on również poinformował o następujących problemach, które również zostały naprawione:
- CVE-2026-40701 (commitu) use-after-free przy użyciu ssl_verify_client+ssl_ocsp (wydaje się, że bez RCE)
- CVE-2026-42934 (commitu) odczyt poza buforem w parserze utf-8 w specyficznych okolicznościach, może prowadzić do niewielkiego wycieku danych lub awarii procesu roboczego
- CVE-2026-42946 (commitu) nadmierne przydzielanie pamięci i odczyt poza buforem przy użyciu modułów scgi/uwsgi, problem ujawnia się w obecności złośliwego backendu (upstream) przez wskazane protokoły, lub podczas man-in-the-middle komunikacji z backendem, może prowadzić do odczytu pamięci nginx lub awarii procesu roboczego
Źródło: linux.org.ru
