Am 13. Mai wurde eine Schwachstelle im beliebten Webserver nginx, der für stark belastete Systeme verwendet wird, behoben: CVE-2026-42945, die möglicherweise zu RCE führen könnte. Diese Schwachstelle existiert seit 18 Jahren (2008) in Version 0.6.27.
Um sie auszunutzen, muss in der Serverkonfiguration eine bestimmte Kombination von Direktiven vorhanden sein, die nicht bei allen, aber an manchen Stellen vorkommen kann, zum Beispiel:
rewrite ^(.*) \/new?c=1;
set $myvar $1;
return 200 $myvar;
Wesentliche Details:
- Zuerst kommt die rewrite-Direktive, bei der (das erste Argument) der reguläre Ausdruck mit einem extrahierten Parameter (etwas in runden Klammern) durch (das zweite Argument) einen Pfad, der ein Fragezeichen enthält, ersetzt wird;
- die set-Direktive (stattdessen könnte auch eine zweite rewrite oder if verwendet werden), die den extrahierten Parameter aus dem ursprünglichen umgeschriebenen Pfad (in diesem Fall $1) nutzt.
Die Schwachstelle funktioniert so:
- Die erste rewrite-Direktive setzt beim Treffen auf das Fragezeichen ein internes Flag is_args, das besagt „wir sammeln jetzt die GET-Parameter für die ersetzte URL, alles muss maskiert werden“, und (das ist der Kern des Bugs) vergisst, dieses Flag am Ende ihrer Arbeit zurückzusetzen;
- Der nachfolgende set-Befehl wendet fälschlicherweise das zuvor festgelegte is_args an, während er den Wert für $myvar bildet, und schreibt den maskierten Wert des ausgewählten Parameters $1 in my_var. Das Problem ist, dass der Puffer für $myvar früher zugewiesen wird, noch bevor die Ersetzungen durchgeführt werden, und seine Länge wird mit is_args=0 berechnet, was bedeutet, dass der maskierte Wert länger ist als der zugewiesene Puffer, wodurch die Schreiboperation außerhalb des zugewiesenen Puffers in andere Serverdatenstrukturen erfolgt. Um dies zu erreichen, genügt es, eine Anfrage mit zu maskierenden Zeichen, beispielsweise Pluszeichen, an der Stelle der Zuordnung des regulären Ausdrucks zu senden.
Wenn auf dem Host kein ALSR vorhanden ist, kann diese Schwachstelle für die Remote-Ausführung von Code mit den Rechten des nginx-Arbeitsprozesses ausgenutzt werden. PoC (dort kein reiner Exploit, Demo in der Sandbox).
Die Schwachstelle wurde im stabilen Zweig nginx 1.30.1 und im neuen Entwicklungszweig 1.31.0 behoben. Link zum Commit.
Interessanterweise wurde vor 14 Jahren (2012) ein ähnlicher Fehler bereits an anderer Stelle behoben. in der Nähe.
——-
Auf der F5-Website gibt es eine Empfehlung zur vorübergehenden Neutralisierung der Sicherheitsanfälligkeit für den Fall, dass die nginx-Version nicht schnell aktualisiert werden kann – unbenannte Parameter sollten durch benannte ersetzt werden, und in diesem Fall, so deren Aussage, würde die Sicherheitsanfälligkeit nicht auftreten. Ein Beispiel von dort:
war: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
ist: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
Die Informationen über die Sicherheitsanfälligkeit wurden von Zhenpeng (Leo) Lin von DepthFirst bereitgestellt. Außerdem berichtete er über folgende Probleme, die ebenfalls behoben wurden:
- CVE-2026-40701 (Commit) Use-after-free bei Verwendung von ssl_verify_client+ssl_ocsp (anscheinend ohne RCE)
- CVE-2026-42934 (Commit) Pufferüberlauf im utf-8-Parser unter spezifischen Umständen, was zu einem kleinen Datenaustritt oder einem Absturz des Arbeitsprozesses führen kann
- CVE-2026-42946 (Commit) Übermäßige Speicherauslagerung und Pufferüberlauf bei Verwendung der scgi/uwsgi-Module, das Problem tritt auf, wenn ein bösartiger Backend über die angegebenen Protokolle vorhanden ist oder bei einem MITM-Angriff auf die Kommunikation mit dem Backend, was dazu führen kann, dass nginx-Speicher gelesen oder der Arbeitsprozess abgestürzt wird.
Quelle: linux.org.ru
