Am 13. Mai wurde eine Sicherheitslücke im nginx-Webserver, einer beliebten Wahl für Systeme mit hoher Auslastung, behoben: CVE-2026-42945Dies kann potenziell zu Remote Code Execution (RCE) führen. Die Sicherheitslücke trat vor 18 Jahren (im Jahr 2008) in Version 0.6.27 auf.
Um es nutzen zu können, muss die Serverkonfiguration eine bestimmte Kombination von Direktiven enthalten, die nicht in allen Fällen, aber an einigen Stellen vorhanden sind, zum Beispiel:
rewrite ^(.*) /new?c=1;
setze $myvar $1;
return 200 $myvar;
Wichtige Details:
- Zuerst kommt die Rewrite-Direktive, wobei (das erste Argument) ein regulärer Ausdruck mit einem auswählbaren Parameter (etwas in Klammern) ist, der durch (das zweite Argument) einen Pfad, der ein Fragezeichen enthält, ersetzt wird;
- Die Set-Direktive (die zweite Rewrite- oder if-Anweisung funktioniert stattdessen auch), die den ausgewählten Parameter aus dem ursprünglich umgeschriebenen Pfad verwendet (in diesem Fall $1).
Die Sicherheitslücke funktioniert folgendermaßen:
- Die erste Rewrite-Direktive setzt beim Auftreffen auf ein Fragezeichen das interne is_args-Flag, was bedeutet: „Wir sammeln jetzt GET-Parameter für die ersetzte URL, alles muss maskiert werden“, und (das ist der Kern des Fehlers) vergisst, dieses Flag am Ende ihrer Arbeit zurückzusetzen;
- Die nachfolgende Set-Anweisung, die einen Wert für `$myvar` generiert, wendet fälschlicherweise die zuvor festgelegte Variable `is_args` an und schreibt den maskierten Wert des zugewiesenen Parameters `$1` in `my_var`. Das Problem besteht darin, dass der Puffer für `$myvar` vor den Ersetzungen reserviert und seine Länge mit `is_args=0` berechnet wird. Dadurch ist der maskierte Wert länger als der reservierte Puffer, was zu Schreibvorgängen in andere Server-Datenstrukturen außerhalb des reservierten Puffers führt. Um dies zu erreichen, genügt es, eine Anfrage mit zu maskierenden Zeichen, wie z. B. Pluszeichen, an der Stelle des regulären Ausdrucksparameters zu senden.
Wenn auf dem Host kein ALSR vorhanden ist, kann diese Schwachstelle ausgenutzt werden, um Code mit den Berechtigungen des nginx-Worker-Prozesses remote auszuführen. PoC (Dies ist kein reiner Exploit, sondern eine Demonstration in einer Sandbox.)
Die Sicherheitslücke wurde im stabilen Zweig von nginx 1.30.1 und im neuen Entwicklungszweig 1.31.0 behoben. Commit-Link.
Es ist bemerkenswert, dass vor 14 Jahren (2012) ein ähnlicher Fehler auftrat. bereits korrigiert an einem anderen Ort in der Nähe.
---
Die F5-Website empfiehlt eine temporäre Abhilfemaßnahme für die Sicherheitslücke, falls ein schnelles Update der NGINX-Version nicht möglich ist. Ersetzen Sie unbenannte dedizierte Parameter durch benannte. Dadurch soll die Sicherheitslücke laut F5 nicht mehr auftreten. Ein Beispiel von dort:
war: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
wurde zu: rewrite ^/users/(? [0-9]+)/Profil/(? .*)$ /profile.php?id=$user_id&tab=$section last;
Die Sicherheitslücke wurde von Zhenpeng (Leo) Lin von DepthFirst gemeldet. Er meldete außerdem die folgenden Probleme, die inzwischen behoben wurden:
- CVE-2026-40701 (verpflichten) Use-After-Free-Fehler bei Verwendung von ssl_verify_client+ssl_ocsp (anscheinend ohne RCE)
- CVE-2026-42934 (verpflichtenDas Lesen von Daten außerhalb des Puffers im UTF-8-Parser kann unter bestimmten Umständen zu einem kleinen Datenleck oder einem Absturz des Workerprozesses führen.
- CVE-2026-42946 (verpflichtenBei Verwendung der SCGI/UWSGI-Module kann es zu übermäßiger Speicherbelegung und Lesezugriffen außerhalb des zulässigen Speicherbereichs kommen. Das Problem manifestiert sich bei einem bösartigen Backend (Upstream) über die angegebenen Protokolle oder bei einem Man-in-the-Middle-Angriff auf den Kommunikationskanal zum Backend. Dies kann zum Auslesen des Nginx-Speichers oder zum Absturz des Worker-Prozesses führen.
Source: linux.org.ru
