Am 13. Mai wurde eine Schwachstelle im beliebten Webserver nginx, der für stark belastete Systeme genutzt wird, behoben: CVE-2026-42945, die potenziell zu RCE führen könnte. Die Schwachstelle trat vor 18 Jahren (2008) in der Version 0.6.27 auf.
Um sie auszunutzen, muss im Serverkonfigurationsfile eine bestimmte Kombination von Direktiven definiert sein, die nicht bei allen vorhanden ist, aber an manchen Stellen vorkommt, beispielsweise:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Wesentliche Details:
- zuerst kommt die Direktive rewrite, bei der (das erste Argument) ein regulärer Ausdruck mit einem erfassten Parameter (etwas in runden Klammern) durch (das zweite Argument) einen Pfad, der ein Fragezeichen enthält, ersetzt wird;
- die Direktive set (anstatt dessen könnte auch der zweite rewrite oder if verwendet werden), die den erfassten Parameter aus dem umgeschriebenen ursprünglichen Pfad nutzt (in diesem Fall ist das $1).
Die Schwachstelle funktioniert folgendermaßen:
- die erste Direktive rewrite setzt beim Auftreffen auf das Fragezeichen ein internes Flag is_args, was bedeutet: „Wir sammeln jetzt die GET-Parameter für die ersetzte URL, wir müssen alles escapen“, und (darum geht es bei dem Bug) vergisst, dieses Flag am Ende ihrer Arbeit zurückzusetzen;
- die nachfolgende Direktive set wendet fälschlicherweise das zuvor gesetzte is_args an, als sie einen Wert für $myvar bildet, und schreibt den escapespeicherten Wert des erfassten Parameters $1 in my_var; das Problem ist, dass der Puffer für $myvar vorher reserviert wird, noch bevor die Substitutionen ausgeführt werden, und seine Länge mit is_args=0 berechnet wird, das heißt, der escapen Wert ist länger als der reservierte Puffer, weshalb die Schreibvorgänge außerhalb des reservierten Puffers in andere Datenstrukturen des Servers stattfinden. Um dies zu erreichen, reicht es aus, eine Anfrage mit Zeichen zu senden, die escapespeichert werden müssen, zum Beispiel mit Pluszeichen, an der Stelle des erfassten Parameters des regulären Ausdrucks.
Wenn auf dem Host kein ALSR vorhanden ist, kann diese Schwachstelle ausgenutzt werden, um Code mit den Rechten des nginx-Arbeitsprozesses remote auszuführen, es gibt PoC (es gibt keinen Exploit in reinem Sinne, eine Demonstration in einer Sandbox).
Die Schwachstelle wurde in der stabilen Version nginx 1.30.1 und in der neuen Entwicklerversion 1.31.0 behoben. Link zum Commit.
Bemerkenswert ist, dass vor 14 Jahren (2012) ein ähnlicher Fehler bereits an anderer Stelle behoben wurde. in der Nähe.
——-
Auf der Website von F5 gibt es eine Empfehlung zur vorübergehenden Neutralisierung der Schwachstelle, falls ein schnelles Update der nginx-Version nicht möglich ist — die namenlosen Parameter sollen durch benannte Parameter ersetzt werden, und in diesem Fall, laut deren Aussage, wird die Schwachstelle nicht auftreten. 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;
Informationen zur Schwachstelle wurden von Zhenpeng (Leo) Lin von DepthFirst zur Verfügung gestellt. Außerdem berichtete er über die folgenden Probleme, die ebenfalls behoben wurden:
- CVE-2026-40701 (Commits) use-after-free bei der Verwendung von ssl_verify_client+ssl_ocsp (scheinbar ohne RCE)
- CVE-2026-42934 (Commits) Lesen über das Bufferende im utf-8-Parser unter bestimmten Umständen, was zu einer geringen Datenleckage oder einem Absturz des Arbeitsprozesses führen kann.
- CVE-2026-42946 (Commits) übermäßige Speicherzuweisung und Lesen über das Bufferende bei der Verwendung von scgi/uwsgi-Modulen, das Problem tritt auf, wenn ein böswilliges Backend (upstream) über die angegebenen Protokolle vorhanden ist oder bei einem MitM-Angriff auf die Kommunikation mit dem Backend, was zum Lesen des Speichers von nginx oder einem Absturz des Arbeitsprozesses führen kann.
Quelle: linux.org.ru
