NGINX Rift

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.

Der Bug (TL;DR)

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:

• Längenlauf sieht is_args = 0 → liefert die rohe Erfassungslänge zurück.
• Kopierlauf sieht 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.

Betroffene und behobene Versionen

Vollständige Herstellerempfehlung: https://my.f5.com/manage/s/article/K000160932

Privater Forschungs-Fork: ASLR-fähige Remote-Lab-Kette

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:

• verwundbare Route: /api/...
• PHP-Local-File-Read-Route: /lfi.php?file=...
• phpinfo-Hinweis-Route: /phpinfo.php
• HTTP/2-Opferverbindung: derselbe nginx-Listener und -Worker
• Nachweisprüfung: Markierungsdatei über den PHP-LFI-Endpunkt zurückgelesen

Der aktuelle coreless-proc-mem-Pfad führt die folgenden Schritte auf hoher Ebene aus:

1. Verwendet PHP-LFI, um die PHP-Identität, nginx-PID-Dateien, /proc/<pid>/maps des nginx-Workers und die gemappte libc-Datei zu lesen.
2. Parst die Ziellibc über LFI, um die absolute Adresse von system() für diesen Worker zu berechnen.
3. Sendet den normalen NGINX-Rift-Spray-/Probe-Traffic, während der Worker-Zustand aktiv bleibt.
4. Liest gemappte Bereiche aus /proc/<worker>/mem über die Dateilese-Primitive.
5. Durchsucht den aktiven Speicher nach nonce-markierten Fake-Cleanup-Strukturen und Cleanup-Pool-Kandidaten.
6. Verwendet begrenzte Endkandidaten, die aus dem aktiven Worker-Speicher abgeleitet werden, nicht hartkodierte Labor-Offsets oder lesbare Crash-Cores.
7. Verifiziert die Befehlsausführung, indem die Markierungsausgabe über die Dateilese-Primitive gelesen wird.

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.

Umfang und Einschränkungen

Dieser Fork ist ein kontrolliertes Forschungslabor. Die ASLR-fähigen Ketten basieren auf strengen Bedingungen, die keine universellen Produktionsannahmen sind:

• PHP muss eine brauchbare Local-File-Read-Primitive bereitstellen.
• Für den standardmäßigen coreless-proc-mem-Pfad muss PHP in der Lage sein, /proc/<pid>/maps des nginx-Workers mit derselben UID, die gemappte libc und /proc/<pid>/mem an großen gemappten Offsets zu lesen.
• Für den Legacy-Core-Guided-Pfad muss PHP in der Lage sein, /proc/<pid>/maps des nginx-Workers mit derselben UID, die gemappte libc und den erzeugten Worker-Core zu lesen.
• HTTP/2 ist auf demselben nginx-Listener aktiviert, um das Connection-Pool-Cleanup-Ziel bereitzustellen, das die finale Kette verwendet.

phpinfo() und /proc/<pid>/maps reichen aus, um PIE-/libc-Basisadressen wiederherzustellen, aber sie reichen allein nicht aus, um das exakte Heap-Objekt/-Fenster wiederherzustellen, das für diesen Exploit benötigt wird. Die alte Kette verwendete für diese finale Offenlegung einen lesbaren Crash-Core. Die aktuelle Standardkette verwendet stattdessen /proc/<worker>/mem, was in Same-UID-Deployments näher an einer echten Arbitrary-File-Read-Konsequenz liegt, da es den aktiven Worker-Speicher offenlegt, ohne die Core-Dump-Richtlinie zu ändern.

Wichtige verbleibende Einschränkungen:

• /proc/<pid>/mem ist ptrace-geschützt. Es funktionierte im Docker-Labor und in einem Same-UID-Check gegen das offizielle nginx:stable-Image-Modell, aber App-Prozesse mit anderer UID sollten unter den Standard-procfs-Schutzmechanismen fehlschlagen.
• Die Dateilese-Primitive muss große Offsets oder eine äquivalente Bereichs-API unterstützen.
• Ein erneuter Test der proc-mem-Kette auf einer echten Ubuntu-VM steht noch aus.
• Ein direkter Non-LFI-Speicherleck in nginx-Antworten wurde nicht gefunden. Passive Reflexion, Redirect-/Header-/Body-Probes, ein anfänglicher Delayed-Proxy-Overread-Sweep und eine SSRF-gestützte Quellcodeprüfung haben keine ASLR-relevante Offenlegung ergeben.

Aktuelle Werkzeuge

Der aktuelle saubere Einstiegspunkt ist nginx_rifter.py, ein Assessment-First-Werkzeug, das näher daran sein soll, wie ein autorisierter Tester eine bekannte verwundbare nginx-Bereitstellung mit einer HTTP-erreichbaren Local-File-Read-Primitive bewerten würde.

Im Vergleich zum ursprünglichen Demo-Runner verbessert nginx_rifter.py den Workflow in mehrfacher Hinsicht:

• Assessment ist die Standardeinstellung. Es führt den crashenden Exploit nicht aus, es sei denn, --exploit wird explizit angegeben.
• Das Ziel wird als HOST:PORT angegeben, und die Dateilese-Primitive ist über --file-read-template modular.
• Es profiliert die LFI-Primitive, bevor es sich auf sie verlässt, einschließlich Text-, Binär- und Bereichslesevorgängen, /proc/self/status, /proc/self/maps und der Erreichbarkeit von procfs für Worker mit derselben UID.
• Es ermittelt über die Remote-Primitive nginx-Worker-Maps, libc, system(), Build-IDs, Binär-Hashes, OS-Details und proc-mem-/Core-Einstellungen.
• Es versucht, die nginx-Konfiguration aus der Master-Cmdline und gängigen Konfigurationspfaden zu ermitteln und markiert dann verwundbare rewrite- + set-Routen-Kandidaten.
• Es gibt eine Machbarkeitsmatrix für Exploit-Ketten aus, damit fehlende Voraussetzungen vor jedem Exploit-Versuch sichtbar sind.
• Der Exploit-Modus ist explizit und in nginx_rifter.py integriert; die Standardmethode ist coreless proc-mem.

Das aktuelle nginx_rifter.py ist eigenständig. Es importiert oder ruft nicht mehr frühere Demo-PoC-Versionen oder tools/proc_mem_coreless_exploit.py für Assessment oder Exploitation auf.

Die ältere core-guided Implementierung von nginx_rifter.py ist als nginx_rifter_core_v2_1.py erhalten.

Das neuere artifacts/nginx_rifter_v3_coreless_exploit_20260519.gif zeigt den zusammengeführten v3-coreless-Exploit-Pfad von nginx_rifter.py. demo4.gif zeigt den Assessment- und expliziten Exploit-Ablauf des früheren All-in-One-Core-Guided-Toolings. Das frühere nginx-aslr-demo.gif bleibt die ursprüngliche ASLR-fähige Exploit-Demo.

Verwendung

Getestet auf Ubuntu 24.04.3 LTS.

Ursprüngliche Docker-Reproduktion mit deaktiviertem ASLR:

1. ./setup.sh — Container bauen.
2. docker compose -f env/docker-compose.yml up — den verwundbaren NGINX-Server starten.
3. python3 poc.py --shell — eine Shell öffnen.

Für den lokalen Docker-Reproduktionsablauf siehe LAB.md.

Legacy-ASLR-fähige VM-Core-Guided-Kette:

./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast

Assessment-First-v3-Werkzeug:

./nginx_rifter.py --target <target-host>:19321

nginx_rifter.py ist der aktuelle realitätsorientierte Assessor und integrierte PoC-Einstiegspunkt. Sein Standardmodus führt den crashenden Exploit-Pfad nicht aus. Es profiliert die HTTP-Dateilese-Primitive, prüft Bereichs- und Binärlesevorgänge, erstellt Fingerabdrücke von OS/nginx/libc, entdeckt nginx-Worker und ASLR-relevante Maps, testet die Lesbarkeit von /proc/<worker>/mem mit derselben UID, versucht, nginx-Konfigurationspfade über PID-/Cmdline-/Config-Reads wiederherzustellen, markiert verwundbare rewrite- + set-Routen-Kandidaten und gibt eine Machbarkeitsmatrix für die aktuelle coreless-Kette aus.

Das aktuelle nginx_rifter.py ist eigenständig. Es importiert oder ruft nicht mehr frühere Demo-PoC-Versionen oder die eigenständige proc-mem-Forschungsumgebung für Assessment oder Exploitation auf.

Für eine benutzerdefinierte LFI-/Download-Form:

./nginx_rifter.py --target <target-host>:19321 \
  --file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'

Die Exploit-Ausführung ist explizit:

./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id --fast

# Discovery-only exploit smoke test, no spray/probe
./nginx_rifter.py --target <target-host>:19321 --exploit --derive-only --cmd id

Die Standard-Exploit-Methode ist coreless proc-mem. Die folgenden Optionen sind bereits standardmäßig ausgewählt, da sie für den Coreless-Docker-Beweis am zuverlässigsten waren:

--exploit-method proc-mem
--target-len 6
--max-region 268435456

Der Legacy-Modus mit lesbarem Core ist weiterhin zum Vergleich verfügbar, aber das versionierte Skript ist für die Reproduktion dieses älteren Pfads klarer:

./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast

Legacy-Terminal-Demo für Aufnahmen:

./demo_ctf_exploit_v1_9.py --host <target-host>:19321 --cmd id --clear

demo_ctf_exploit_v1_9.py ist der ältere, bedienerorientierte Runner für den Core-Guided-Lab-Pfad. Der aktuell bevorzugte PoC-Einstiegspunkt ist nginx_rifter.py.

Die Standard-Dateilese-Primitive ist diese PHP-Route des Forks:

/lfi.php?file=<path>&offset=<n>&length=<n>

Für eine andere bekannte verwundbare CTF-App oder Testplattform ist der Dateilese-Vektor modular:

./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id \
  --target-profile generic \
  --file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'

Die Vorlage unterstützt {host}, {port}, {path_url}, {offset}, {length} und {range_query}. Das generische Profil überspringt die labspezifischen nginx-Konfigurationsprüfungen dieses Forks, aber der Standard-Exploit benötigt weiterhin dieselben zugrunde liegenden Fähigkeiten: lesbare nginx-Worker-/proc-Maps, lesbare libc und lesbares /proc/<worker>/mem. phpinfo() ist optional; verwenden Sie --phpinfo-path '', um es zu deaktivieren.

Realismus-Warnung: Die LFI-/Dateilese-Schwachstellenklasse und das Deployment-Modell mit nginx/PHP-FPM auf demselben Host sind realistisch. Die proc-mem-Kette ist realistischer als die frühere Crash-Core-Kette, da sie das Aktivieren oder Lesen von Worker-Core-Dumps nicht erfordert. Sie ist dennoch keine universelle Standard-Produktionsannahme: Das Prozesslayout mit derselben UID, die procfs/Yama-Richtlinie, Container-Namespace-Einstellungen und die Qualität der Dateilese-Primitive entscheiden, ob /proc/<worker>/mem erreichbar ist.

No-LFI-Forschungssonden:

python3 tools/non_lfi_leak_probe.py --target <target-host>:19321
python3 tools/non_lfi_active_response_probe.py --target <target-host>:19321

Dies sind negative Forschungssonden, keine Exploit-Einstiegspunkte. Sie testen passive reflektierte Senken und eine anfängliche Delayed-Response-Overread-Form, ohne LFI, phpinfo, procfs, Cores, Debugger-Zugriff oder hartkodierte Live-ASLR-Basen zu verwenden.

Zusätzliche Laborhinweise und Laufprotokolle befinden sich unter docs/, insbesondere:

• docs/CTF_PLAN.md
• docs/CTF_FINDINGS.md
• docs/CTF_TESTS.md
• docs/CTF_EXPERIMENT_LOG.md
• docs/DEMO_POC_IMPROVEMENTS.md
• docs/KNOWN_LAYOUT_PATTERNS.md
• docs/VAGRANT_ESXI.md
• docs/CORELESS_ASLR_PLAN.md
• docs/CORELESS_ASLR_FINDINGS.md
• docs/NON_LFI_ASLR_BYPASS_LOG.md
• docs/DEMO_RECORDING_WORKFLOW.md