Pe 13 mai a fost corectată o vulnerabilitate în popularul server web nginx, utilizat în sistemele cu sarcini mari: CVE-2026-42945, care ar putea duce la RCE. Vulnerabilitatea a apărut acum 18 ani (în 2008) în versiunea 0.6.27.
Pentru a o exploata, în configurația serverului trebuie să existe o combinație specifică de directive, nu neapărat folosită de toți, dar care poate apărea în anumite locuri, cum ar fi:
rewrite ^(.*) \/new?c=1;
set $myvar $1;
return 200 $myvar;
Detalii esențiale:
- mai întâi apare directiva rewrite, unde (primul argument) o expresie regulată cu parametru extras (ceva în paranteze) este înlocuită cu (al doilea argument) un căi care conține semnul întrebării;
- directiva set (în locul ei poate fi folosită și a doua directivă rewrite sau if), care utilizează parametrul extras din calea re-scrierei originale (în acest caz, $1).
Vulnerabilitatea funcționează astfel:
- prima directivă rewrite, întâlnind semnul întrebării, setează un steag intern is_args, care semnifică "acum colectăm parametrii get pentru url-ul înlocuit, trebuie să escapăm tot", și (aceasta este esența bug-ului) uită să reseteze acest steag la finalul operațiunii sale;
- directiva set ulterioară, la formarea valorii pentru $myvar, aplică în mod greșit is_args setat anterior, și scrie în my_var valoarea escapată a parametrului extras $1; problema este că buffer-ul pentru $myvar este alocat mai devreme, înainte de a efectua înlocuirile, iar lungimea sa este calculată cu is_args=0, ceea ce înseamnă că valoarea escapată devine mai lungă decât buffer-ul alocat, astfel încât scrierea se face în afara acestui buffer, în alte structuri de date ale serverului. Pentru ca acest lucru să se întâmple, este suficient să se trimită o cerere cu caractere care necesită escapare, de exemplu, semnele „plus”, în locul în care se extrage parametrul expresiei regulate.
Dacă pe host nu există ASLR, această vulnerabilitate poate fi exploatată pentru execuția de cod de la distanță cu drepturile procesului de lucru nginx, există PoC (nu este un exploit în sine, ci o demonstrație în sandbox).
Vulnerabilitatea a fost corectată în ramura stabilă nginx 1.30.1, și în noua ramură de dezvoltare 1.31.0. link către commit.
Este notabil că acum 14 ani (în 2012) o eroare similară a fost deja corectată în altă parte din apropiere.
——-
Pe site-ul F5 există o recomandare pentru neutralizarea temporară a vulnerabilității în cazul în care actualizarea rapidă a versiunii nginx nu este posibilă — trebuie să înlocuiți parametrii neîntitulați cu cei intitulați, iar în acest caz, spun ei, vulnerabilitatea nu se va manifesta. Exemplu de acolo:
a fost: rewrite ^\/users\/([0-9]+)\/profile\/(.*)$ \/profile.php?id=$1&tab=$2 last;
a devenit: rewrite ^\/users\/(?<user_id>[0-9]+)\/profile\/(?<section>.*)$ \/profile.php?id=$user_id&tab=$section last;
Informațiile despre vulnerabilitate au fost furnizate de Zhenpeng (Leo) Lin de la DepthFirst. În plus, el a raportat și următoarele probleme care au fost de asemenea remediate:
- CVE-2026-40701 (commit) utilizare după eliberare la folosirea ssl_verify_client+ssl_ocsp (aparent fără RCE)
- CVE-2026-42934 (commit) citire dincolo de buffer în parserul utf-8 în circumstanțe specifice, poate duce la o mică scurgere de date sau la prăbușirea procesului de lucru
- CVE-2026-42946 (commit) alocare excesivă de memorie și citire dincolo de buffer la utilizarea modulelor scgi\/uwsgi, problema se manifestă în prezența unui backend rău intenționat (upstream) prin protocoalele specificate, sau în timpul unui attac mitm asupra canalului de comunicare cu backend-ul, poate duce la citirea memoriei nginx sau la prăbușirea procesului de lucru
Sursa: linux.org.ru
