Privates Nginx Rift ASLR-Labor, Exploit-Kette und Demo-Aufzeichnungen
RCE-Proof of Concept für CVE-2026-42945, einen kritischen Heap-Buffer-Overflow in NGINXs ngx_http_rewrite_module, der 2008 eingeführt wurde. Der Bug ermöglicht nicht authentifizierte Remote-Codeausführung gegen Server, die rewrite- und set-Direktiven verwenden.
Dieser Fork erweitert das ursprüngliche PoC um eine ASLR-Bypass-Kette, die den NGINX-Overflow mit einer gängigen Same-Host-LFI-/Arbitrary-File-Read-Primitive kombiniert. Die Dateilese-Primitive wird verwendet, um nginx-Worker-Maps, libc und das Live-/proc/<worker>/mem wiederherzustellen und daraus die Adresse von system() sowie nutzbare Heap-Ziele remote abzuleiten.
Frühere Versionen dieses Labs haben absichtlich einen nginx-Worker zum Absturz gebracht, damit der Dienst einen Core-Dump schreibt, und diesen Core-Dump dann über die Dateilese-Primitive abgerufen und geparst, um ASLR-sensitiven Prozesszustand einschließlich Heap-Zielen wiederherzustellen. In diesem Repo ist coreless nur eine Kurzform für „ohne lesbaren Crash-Core-Dump": Der aktuelle Standardpfad ersetzt diese Crash-Core-Abhängigkeit durch Live-procfs-Speicherlesevorgänge, während der erhaltene Legacy-core-guided-Pfad weiterhin den erzeugten Worker-Core-Dump verwendet.
Diese Schwachstelle — zusammen mit drei weiteren Speicherkorruptionsproblemen (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — wurde von depthfirsts Sicherheitsanalysesystem nach einem einzigen Klick zum Onboarding des NGINX-Quellcodes autonom entdeckt.
Möchten Sie solche Probleme in Ihrem eigenen Code finden? Probieren Sie dasselbe System unter https://depthfirst.com/open-defense aus.
Die Skript-Engine von NGINX verwendet einen zweistufigen Prozess: Zuerst wird die erforderliche Puffergröße berechnet, dann werden die Daten kopiert. Das Flag is_args wird an der Haupt-Engine gesetzt, wenn eine rewrite-Ersetzung ? enthält, aber der Längenberechnungslauf läuft auf einer frisch genullten Unter-Engine. Also:
is_args = 0 → liefert die rohe Erfassungslänge zurück.is_args = 1 → ruft ngx_escape_uri mit NGX_ESCAPE_ARGS auf und expandiert jedes escapbare Byte auf 3 Bytes.Der Kopiervorgang lässt den zu kleinen Heap-Puffer mit angreiferkontrollierten URI-Daten überlaufen. Die Ausnutzung verwendet Cross-Request-Heap-Feng-Shui, um den cleanup-Zeiger eines angrenzenden ngx_pool_t zu korrumpieren (über POST-Bodies gesprayt, da URI-Bytes keine Null-Bytes enthalten können), und leitet ihn auf eine gefälschte ngx_pool_cleanup_s-Struktur um, die bei der Pool-Zerstörung system() aufruft.
Lesen Sie mehr über diesen Bug in unserem technischen Write-up.
| Produkt | Betroffen | Behoben in |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |
| NGINX Plus | R32 – R36 | R36 P4, R35 P2, R32 P6 |
Vollständige Herstellerempfehlung: https://my.f5.com/manage/s/article/K000160932
Dieser Fork lässt das ursprüngliche Offenlegungs-PoC intakt, fügt aber eine zweite Forschungsspur hinzu, die sich auf eine realistischere Frage konzentriert:
Kann der Bug gegen eine echte x86_64-Linux-VM mit aktiviertem ASLR ausgenutzt werden, ohne auf hartkodierte Docker-/Labor-Offsets angewiesen zu sein?
Die Antwort in diesem Forschungs-Fork lautet ja, mit wichtigen Einschränkungen. Die funktionierenden Ketten deaktivieren ASLR nicht und verwenden nicht die ursprünglichen hartkodierten Heap-/libc-Adressen. Stattdessen leiten sie den Laufzeitzustand über HTTP-erreichbare Primitiven auf demselben Port ab und wählen dann das endgültige Heap-Ziel aus remote gewonnenen Offenlegungsdaten.
Es gibt nun zwei ASLR-fähige Exploit-Spuren, wobei der coreless-Pfad als aktuelles bestes PoC behandelt wird:
nginx_rifter.py: der saubere, eigenständige Assessment- und integrierte Exploit-Einstiegspunkt. Seine Standard-Exploit-Methode ist jetzt die coreless-/proc/<nginx-worker>/mem-Kette.nginx_rifter_core_v2_1.py: die erhaltene Legacy-Core-Guided-Version von nginx_rifter.py. Sie ist nützlich, um den älteren, auf VMs getesteten Crash-Core-Forschungspfad zu reproduzieren, ist aber nicht mehr das bevorzugte PoC.tools/proc_mem_coreless_exploit.py: die frühere eigenständige coreless-Forschungsumgebung. Ihre Logik wurde in nginx_rifter.py zusammengeführt; das Werkzeug bleibt für das rohe Experiment-Replay erhalten.Die Zieltopologie ist absichtlich auf demselben Port:
/api/.../lfi.php?file=.../phpinfo.phpDer aktuelle coreless-proc-mem-Pfad führt die folgenden Schritte auf hoher Ebene aus:
/proc/<pid>/maps des nginx-Workers und die gemappte libc-Datei zu lesen.system() für diesen Worker zu berechnen./proc/<worker>/mem über die Dateilese-Primitive.Der Legacy-Core-Guided-Pfad führt eine ähnliche Basisadressableitung durch, bringt dann absichtlich einen Worker zum Absturz, liest die erzeugte Core-Datei über LFI und durchsucht diesen Core nach gesprayten Fake-Cleanup-Slots. Das war eine nützliche Forschungsbrücke, hängt aber von Core-Dump-Richtlinien und Dateisystemberechtigungen ab, die in Standard-Deployments weniger verbreitet sind.
Dies ist nicht dasselbe wie die ursprüngliche deterministische Docker-Demo. Der x86_64-VM-Pfad lässt normales Linux-ASLR aktiviert und berechnet prozessspezifische Adressen bei jedem Lauf neu. Der Docker-Coreless-Pfad lässt ASLR ebenfalls aktiviert und entfernt die ungewöhnliche Anforderung an lesbare Cores, hängt aber von procfs-Berechtigungsverhalten ab, das für die Zielklasse verifiziert werden muss.
Dieser Fork ist ein kontrolliertes Forschungslabor. Die ASLR-fähigen Ketten basieren auf strengen Bedingungen, die keine universellen Produktionsannahmen sind:
/proc/<pid>/maps des nginx-Workers mit derselben UID, die gemappte libc und /proc/<pid>/mem an großen gemappten Offsets zu lesen./proc/<pid>/maps des nginx-Workers mit derselben UID, die gemappte libc und den erzeugten Worker-Core zu lesen.