[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-79981":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":14,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":17,"hasPages":17,"topics":19,"createdAt":9,"pushedAt":9,"updatedAt":20,"readmeContent":21,"aiSummary":22,"trendingCount":14,"starSnapshotCount":14,"syncStatus":15,"lastSyncTime":23,"discoverSource":24},79981,"nginx-rift-private-lab","Hamid-K\u002Fnginx-rift-private-lab","Hamid-K","Private Nginx Rift ASLR lab, exploit chain, and demo recordings",null,"Python",74,15,73,0,2,40.81,false,"main",[],"2026-06-12 04:01:26","# NGINX Rift\n\nRCE Proof of concept for **CVE-2026-42945**, a critical heap buffer overflow in NGINX's `ngx_http_rewrite_module` introduced in 2008. The bug enables unauthenticated remote code execution against servers using `rewrite` and `set` directives.\n\nThis fork extends the original PoC with an ASLR-bypass chain that combines the NGINX overflow with a common same-host LFI\u002Farbitrary-file-read primitive. The file-read primitive is used to recover nginx worker maps, libc, and live `\u002Fproc\u002F\u003Cworker>\u002Fmem`, then derive the `system()` address and usable heap targets remotely.\n\nEarlier versions of this lab intentionally crashed an nginx worker to make the service write a core dump, then fetched and parsed that core dump through the file-read primitive to recover ASLR-sensitive process state, including heap targets. In this repo, **coreless** is only shorthand for \"without a readable crash core dump\": the current default path replaces that crash-core dependency with live procfs memory reads, while the preserved legacy **core-guided** path still uses the generated worker core dump.\n\nThis vulnerability — along with three other memory corruption issues (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — was autonomously discovered by [depthfirst](https:\u002F\u002Fdepthfirst.com)'s security analysis system after a single click of onboarding the NGINX source.\n\n> Want to find issues like this in your own code? Try the same system at **\u003Chttps:\u002F\u002Fdepthfirst.com\u002Fopen-defense>**.\n\n## The Bug (TL;DR)\n\nNGINX's script engine uses a two-pass process: first compute the required buffer size, then copy data in. The `is_args` flag is set on the main engine when a `rewrite` replacement contains `?`, but the length-calculation pass runs on a freshly zeroed sub-engine. So:\n\n- **Length pass** sees `is_args = 0` → returns raw capture length.\n- **Copy pass** sees `is_args = 1` → calls `ngx_escape_uri` with `NGX_ESCAPE_ARGS`, expanding each escapable byte to 3 bytes.\n\nThe copy overflows the undersized heap buffer with attacker-controlled URI data. Exploitation uses cross-request heap feng shui to corrupt an adjacent `ngx_pool_t`'s `cleanup` pointer (sprayed via POST bodies, since URI bytes can't contain null bytes), redirecting it to a fake `ngx_pool_cleanup_s` invoking `system()` on pool destruction.\n\nRead more about this bug in our [technical write-up](https:\u002F\u002Fdepthfirst.com\u002Fresearch\u002Fnginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability).\n\n## Affected & Fixed Versions\n\n| Product | Affected | Fixed in |\n| --- | --- | --- |\n| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |\n| NGINX Plus | R32 – R36 | R36 P4, R35 P2, R32 P6 |\n\nFull vendor advisory: \u003Chttps:\u002F\u002Fmy.f5.com\u002Fmanage\u002Fs\u002Farticle\u002FK000160932>\n\n## Private Research Fork: ASLR-Enabled Remote Lab Chain\n\n![ASLR-enabled remote exploit demo](nginx-aslr-demo.gif)\n\n![Assessment-first nginx_rifter demo](demo4.gif)\n\n![nginx_rifter v3 coreless proc-mem exploit demo](artifacts\u002Fnginx_rifter_v3_coreless_exploit_20260519.gif)\n\nThis fork keeps the original disclosure PoC intact, but adds a second research track focused on a more realistic question:\n\n> Can the bug be exploited against a real x86_64 Linux VM with ASLR enabled, without relying on hardcoded Docker\u002Flab offsets?\n\nThe answer in this research fork is **yes, with important constraints**. The working chains do not disable ASLR and do not use the original hardcoded heap\u002Flibc addresses. Instead, they derive runtime state through same-port HTTP-accessible primitives, then select the final heap target from remotely obtained disclosure data.\n\nThere are now two ASLR-enabled exploit tracks, with the coreless path treated as the current best PoC:\n\n- `nginx_rifter.py`: the clean, self-contained assessment and integrated exploit entry point. Its default exploit method is now the coreless `\u002Fproc\u002F\u003Cnginx-worker>\u002Fmem` chain.\n- `nginx_rifter_core_v2_1.py`: the preserved legacy core-guided version of `nginx_rifter.py`. It is useful for reproducing the older VM-tested crash-core research path, but it is no longer the preferred PoC.\n- `tools\u002Fproc_mem_coreless_exploit.py`: the earlier standalone coreless research harness. Its logic has been merged into `nginx_rifter.py`; the tool remains for raw experiment replay.\n\nThe target topology is intentionally same-port:\n\n- vulnerable route: `\u002Fapi\u002F...`\n- PHP local-file-read route: `\u002Flfi.php?file=...`\n- phpinfo hint route: `\u002Fphpinfo.php`\n- HTTP\u002F2 victim connection: same nginx listener and worker\n- proof verification: marker file read back through the PHP LFI endpoint\n\nThe current coreless proc-mem path performs the following high-level steps:\n\n1. Uses PHP LFI to read PHP identity, nginx pid files, nginx worker `\u002Fproc\u002F\u003Cpid>\u002Fmaps`, and the mapped libc file.\n2. Parses the target libc over LFI to compute the absolute `system()` address for that worker.\n3. Sends the normal NGINX Rift spray\u002Fprobe traffic while keeping the worker state live.\n4. Reads mapped ranges from `\u002Fproc\u002F\u003Cworker>\u002Fmem` through the file-read primitive.\n5. Scans live memory for nonce-marked fake-cleanup structures and cleanup-pool candidates.\n6. Uses bounded final candidates derived from live worker memory, not hardcoded lab offsets or readable crash cores.\n7. Verifies command execution by reading the marker output through the file-read primitive.\n\nThe legacy core-guided path performs a similar base-address derivation, then intentionally crashes a worker, reads the generated core file over LFI, and mines that core for sprayed fake-cleanup slots. That was a useful research bridge, but it depends on core-dump policy and filesystem permissions that are less common in default deployments.\n\nThis is not the same as the original deterministic Docker demo. The x86_64 VM path leaves normal Linux ASLR enabled and recomputes process-specific addresses on each run. The Docker coreless path also leaves ASLR enabled and removes the unusual readable-core requirement, but it depends on procfs permission behavior that must be verified for the target class.\n\n### Scope And Caveats\n\nThis fork is a controlled research lab. The ASLR-enabled chains rely on strong conditions that are not universal production assumptions:\n\n- PHP must expose a useful local-file-read primitive.\n- For the default coreless proc-mem path, PHP must be able to read same-UID nginx worker `\u002Fproc\u002F\u003Cpid>\u002Fmaps`, mapped libc, and `\u002Fproc\u002F\u003Cpid>\u002Fmem` at large mapped offsets.\n- For the legacy core-guided path, PHP must be able to read same-UID nginx worker `\u002Fproc\u002F\u003Cpid>\u002Fmaps`, mapped libc, and the generated worker core.\n- HTTP\u002F2 is enabled on the same nginx listener to provide the connection-pool cleanup target used by the final chain.\n\n`phpinfo()` and `\u002Fproc\u002F\u003Cpid>\u002Fmaps` are enough to recover PIE\u002Flibc base addresses, but they are not enough by themselves to recover the exact heap object\u002Fwindow needed for this exploit. The old chain used a readable crash core for that final disclosure. The current default chain uses `\u002Fproc\u002F\u003Cworker>\u002Fmem` instead, which is closer to a real arbitrary-file-read consequence in same-UID deployments because it exposes live worker memory without changing core-dump policy.\n\nImportant remaining limits:\n\n- `\u002Fproc\u002F\u003Cpid>\u002Fmem` is ptrace-gated. It worked in the Docker lab and in a same-UID check against the official `nginx:stable` image model, but different-UID app processes should fail under default procfs protections.\n- The file-read primitive must support large offsets or an equivalent range API.\n- A real Ubuntu VM retest for the proc-mem path is still pending.\n- A direct non-LFI nginx response memory leak has not been found. Passive reflection, redirect\u002Fheader\u002Fbody probes, an initial delayed-proxy over-read sweep, and an SSRF-assisted source review have not produced ASLR-relevant disclosure.\n\n### Current Tooling\n\nThe current clean entry point is `nginx_rifter.py`, an assessment-first tool intended to be closer to how an authorized tester would evaluate a known vulnerable nginx deployment with an HTTP-accessible local-file-read primitive.\n\nCompared with the initial demo runner, `nginx_rifter.py` improves the workflow in several ways:\n\n- Assessment is the default. It does not run the crashing exploit unless `--exploit` is explicitly supplied.\n- The target is provided as `HOST:PORT`, and the file-read primitive is modular through `--file-read-template`.\n- It profiles the LFI primitive before relying on it, including text reads, binary reads, ranged reads, `\u002Fproc\u002Fself\u002Fstatus`, `\u002Fproc\u002Fself\u002Fmaps`, and same-UID worker procfs reachability.\n- It discovers nginx worker maps, libc, `system()`, build IDs, binary hashes, OS details, and proc-mem\u002Fcore settings through the remote primitive.\n- It attempts nginx config discovery from master cmdline and common config paths, then flags vulnerable `rewrite` + `set` route candidates.\n- It prints an exploit-chain viability matrix so missing prerequisites are visible before any exploit attempt.\n- Exploit mode is explicit and integrated into `nginx_rifter.py`; the default method is coreless proc-mem.\n\nThe current `nginx_rifter.py` is self-contained. It no longer imports or shells out to earlier demo PoC versions or `tools\u002Fproc_mem_coreless_exploit.py` for assessment or exploitation.\n\nThe older core-guided `nginx_rifter.py` implementation is preserved as `nginx_rifter_core_v2_1.py`.\n\nThe newer `artifacts\u002Fnginx_rifter_v3_coreless_exploit_20260519.gif` shows the merged v3 `nginx_rifter.py` coreless exploit path. `demo4.gif` shows the assessment and explicit exploit flow from the earlier all-in-one core-guided tooling. The earlier `nginx-aslr-demo.gif` remains as the original ASLR-enabled exploit demo.\n\n## Usage\n\nTested on Ubuntu 24.04.3 LTS.\n\nOriginal ASLR-disabled Docker reproduction:\n\n1. `.\u002Fsetup.sh` — build the container.\n2. `docker compose -f env\u002Fdocker-compose.yml up` — start the vulnerable NGINX server.\n3. `python3 poc.py --shell` — pop a shell.\n\nFor the local Docker reproduction flow, see [LAB.md](LAB.md).\n\nLegacy ASLR-enabled VM core-guided chain:\n\n```bash\n.\u002Fnginx_rifter_core_v2_1.py --target \u003Ctarget-host>:19321 --exploit --cmd id --fast\n```\n\nAssessment-first v3 tool:\n\n```bash\n.\u002Fnginx_rifter.py --target \u003Ctarget-host>:19321\n```\n\n`nginx_rifter.py` is the current real-world-oriented assessor and integrated PoC entry point. Its default mode does not run the crashing exploit path. It profiles the HTTP file-read primitive, checks ranged and binary reads, fingerprints OS\u002Fnginx\u002Flibc, discovers nginx workers and ASLR-relevant maps, tests same-UID `\u002Fproc\u002F\u003Cworker>\u002Fmem` readability, tries to recover nginx config paths through pid\u002Fcmdline\u002Fconfig reads, flags vulnerable `rewrite` + `set` route candidates, and prints a viability matrix for the current coreless chain.\n\nThe current `nginx_rifter.py` is self-contained. It no longer imports or shells out to earlier demo PoC versions or the standalone proc-mem research harness for assessment or exploitation.\n\nFor a custom LFI\u002Fdownload shape:\n\n```bash\n.\u002Fnginx_rifter.py --target \u003Ctarget-host>:19321 \\\n  --file-read-template 'http:\u002F\u002F{host}:{port}\u002Fdownload?path={path_url}{range_query}'\n```\n\nExploit execution is explicit:\n\n```bash\n.\u002Fnginx_rifter.py --target \u003Ctarget-host>:19321 --exploit --cmd id --fast\n\n# Discovery-only exploit smoke test, no spray\u002Fprobe\n.\u002Fnginx_rifter.py --target \u003Ctarget-host>:19321 --exploit --derive-only --cmd id\n```\n\nThe default exploit method is coreless proc-mem. The following options are already selected by default because they were the most reliable for the coreless Docker proof:\n\n```bash\n--exploit-method proc-mem\n--target-len 6\n--max-region 268435456\n```\n\nThe legacy readable-core mode is still available for comparison, but the versioned script is clearer for reproducing that older path:\n\n```bash\n.\u002Fnginx_rifter_core_v2_1.py --target \u003Ctarget-host>:19321 --exploit --cmd id --fast\n```\n\nLegacy recording-friendly terminal demo:\n\n```bash\n.\u002Fdemo_ctf_exploit_v1_9.py --host \u003Ctarget-host>:19321 --cmd id --clear\n```\n\n`demo_ctf_exploit_v1_9.py` is the older operator-facing runner for the core-guided lab path. The current preferred PoC entry point is `nginx_rifter.py`.\n\nThe default file-read primitive is this fork's PHP route:\n\n```text\n\u002Flfi.php?file=\u003Cpath>&offset=\u003Cn>&length=\u003Cn>\n```\n\nFor a different known-vulnerable CTF app or testing platform, the file-read vector is modular:\n\n```bash\n.\u002Fnginx_rifter.py --target \u003Ctarget-host>:19321 --exploit --cmd id \\\n  --target-profile generic \\\n  --file-read-template 'http:\u002F\u002F{host}:{port}\u002Fdownload?path={path_url}{range_query}'\n```\n\nThe template supports `{host}`, `{port}`, `{path_url}`, `{offset}`, `{length}`, and `{range_query}`. The generic profile skips this fork's lab-specific nginx config assertions, but the default exploit still needs the same underlying capabilities: readable nginx worker `\u002Fproc` maps, readable libc, and readable `\u002Fproc\u002F\u003Cworker>\u002Fmem`. `phpinfo()` is optional; use `--phpinfo-path ''` to disable it.\n\nRealism caveat: the LFI\u002Ffile-read bug class and same-host nginx\u002FPHP-FPM deployment model are realistic. The proc-mem chain is more realistic than the earlier crash-core chain because it does not require enabling or reading worker core dumps. It is still not a universal default-production assumption: same-UID process layout, procfs\u002FYama policy, container namespace settings, and the quality of the file-read primitive decide whether `\u002Fproc\u002F\u003Cworker>\u002Fmem` is reachable.\n\nNo-LFI research probes:\n\n```bash\npython3 tools\u002Fnon_lfi_leak_probe.py --target \u003Ctarget-host>:19321\npython3 tools\u002Fnon_lfi_active_response_probe.py --target \u003Ctarget-host>:19321\n```\n\nThese are negative research probes, not exploit entry points. They exercise passive reflected sinks and an initial delayed-response over-read shape without using LFI, phpinfo, procfs, cores, debugger access, or hardcoded live ASLR bases.\n\nAdditional lab notes and run logs are under `docs\u002F`, especially:\n\n- `docs\u002FCTF_PLAN.md`\n- `docs\u002FCTF_FINDINGS.md`\n- `docs\u002FCTF_TESTS.md`\n- `docs\u002FCTF_EXPERIMENT_LOG.md`\n- `docs\u002FDEMO_POC_IMPROVEMENTS.md`\n- `docs\u002FKNOWN_LAYOUT_PATTERNS.md`\n- `docs\u002FVAGRANT_ESXI.md`\n- `docs\u002FCORELESS_ASLR_PLAN.md`\n- `docs\u002FCORELESS_ASLR_FINDINGS.md`\n- `docs\u002FNON_LFI_ASLR_BYPASS_LOG.md`\n- `docs\u002FDEMO_RECORDING_WORKFLOW.md`\n","该项目是一个针对NGINX中CVE-2026-42945漏洞的远程代码执行（RCE）概念验证。它通过结合使用一个常见的同主机文件读取原语来绕过地址空间布局随机化（ASLR），从而实现对目标服务器的攻击。核心功能包括利用堆缓冲区溢出漏洞和文件读取漏洞，以获取关键内存信息并执行远程命令。此项目适合于安全研究人员及渗透测试人员在受控环境中学习、研究该类型漏洞及其利用方法。","2026-06-11 03:58:46","CREATED_QUERY"]