srkyn/nginx-map-risk-audit

# CVE-2026-42533：NGINX Map Regex 风险评估 关于 CVE-2026-42533 的防御性研究笔记，这是 NGINX 在处理请求时发生的一个 heap buffer overflow 漏洞，与带有 regex 捕获的 `map` 指令以及某些特定的变量求值模式有关。 简单来说：NGINX 是一款 web server 和反向代理软件。它通常部署在网站和 API 的前端，负责接收 web 请求，并决定将它们发送到哪里。`map` 规则是 NGINX 的一项配置功能，表示“如果此请求的值看起来像 X，则将此变量设置为 Y”。Regex 捕获是指从模式匹配中提取出的文本片段。 这个 CVE 之所以重要，是因为某些较旧的 NGINX 版本在处理特定类型的 `map` 和变量组合模式时可能会出现错误。但这并不意味着每台 NGINX 服务器都面临风险。虽然版本很重要，但当前生效的配置同样关键。 本项目具有固有的安全性：它不包含漏洞利用流量、crash payload 或生产环境探测。目标是展示我将如何对暴露风险进行分类（triage）、解释相关风险，并为防御者提供一条可重复的验证路径。  ## 为什么这很重要 NGINX 将该问题列为重大安全公告：受影响的版本为 `0.9.6-1.31.2`，已修复的版本为 `1.30.4+` 和 `1.31.3+`。NGINX 更新日志描述了当一个 `map` 指令使用 regex 匹配，并且 map 变量在受到该 map 影响的捕获之后被包含在 string expression 中时，worker 进程中会发生的 heap buffer overflow。 NVD 记录了 F5 的描述：未经身份验证的攻击者可能会利用精心构造的 HTTP 请求触发该问题，但前提是配置和运行时条件同时满足。预期的直接影响是 NGINX worker 重启和拒绝服务（denial of service）；如果 ASLR 被禁用或被绕过，则有可能发生代码执行。 ## 暴露风险分类（Exposure Triage） 防御者在将 NGINX 部署视为存在暴露风险之前，应先回答四个问题。简而言之：首先确认版本，然后再确认是否实际存在高风险的配置模式。 1. 正在运行的 NGINX 二进制文件是否处于受影响的上游版本范围内，同时是否考虑了发行版（distro）的向后移植（backport）？ 2. 当前生效的配置是否使用了带有 regex 条目的 `map`？ 3. 映射的 regex 捕获是否在后续的 string expression 中以某种顺序提供，且这种顺序在长度计算阶段和复制阶段之间可能发生变化？ 4. 日志中是否可见可疑的 worker 重启、crash loop，或者是已修复构建中的错误信号 `no buffer space in script copy`？ 如果这些词汇对你来说很陌生：worker 是 NGINX 中处理请求的进程。crash loop 或重启信号意味着该进程可能正在不断失败并重新启动。发行版（distro）向后移植（backport）是指 Linux 供应商有时会在不将版本号更改为最新上游版本的情况下，对看起来较旧的版本进行补丁修复。 ## 工作流一览 ``` flowchart LR advisory["Read advisory and changelog"] --> version["Check NGINX version"] version --> config["Review active config"] config --> scanner["Run safe map-pattern scanner"] scanner --> validate["Validate fixed build or vendor patch"] validate --> hunt["Hunt restart and diagnostic signals"] hunt --> remediate["Patch, reload, and document"] ``` ## 仓库内容 - `scripts/audit_nginx_map_risk.py` 用于 NGINX 配置文件的防御性启发式扫描器。它会查找 regex `map` 块、捕获，以及引用这些捕获和 map 输出的后续 string expression。它不能证明服务器是可被利用的。它的作用是找出值得人工审查的配置。 - `scripts/render_demo_gif.py` 根据真实的扫描器输出重新生成小型的 README 演示 GIF。 - `detections/splunk_nginx_cve_2026_42533.spl` 用于版本清单、崩溃/重启症状以及补丁安装后诊断字符串的 Splunk 搜索规则。 - `detections/defender_hunting_notes.kql` 适用于收集了 NGINX 日志和进程活动的 Linux 主机的 Microsoft Defender 搜寻（hunting）笔记。 - `detections/sigma_nginx_worker_restart_symptoms.yml` 用于 NGINX worker 重启或崩溃症状的 Sigma 搜寻（hunting）规则。它是用于审查的线索，而非被利用的证明。 - `samples/nginx_map_patterns.conf` 用于解释风险模式的安全、示意性配置示例。这些不是 exploit payload。 - `SECURITY.md` 仓库的范围说明。这确保了本项目明确具备防御性且可安全查阅。 - `lab/windows-quickstart.ps1` 对 Windows 友好的证据收集器，可执行扫描器并将输出保存在 `evidence/` 目录下。 - `lab/windows-nginx-validation.ps1` 下载官方已修复的 NGINX for Windows 构建版本，使用 `nginx -t` 验证本地实验配置，运行扫描器并保存证据。 - `lab/vmware-lab-notes.md` 如果以后需要基于截图的操作指南，这是用于一次性 Linux 虚拟机的可选完整实验路径。 ## 证据 当前的本地验证存储在 `evidence/` 中。Windows 快速入门脚本会对包含的示例配置运行扫描器并保存记录。Windows NGINX 验证脚本会下载官方已修复的 NGINX 构建版本，使用 `nginx -t` 确认实验配置，并运行扫描器。Kali 虚拟机验证会在一次性的 Kali VMware 客户机中运行相同的扫描器。这证明了该仓库在 Windows 和 Linux 上均可执行和审查，同时将项目保持在防御性边界之内。 ``` powershell -ExecutionPolicy Bypass -File .\lab\windows-quickstart.ps1 powershell -ExecutionPolicy Bypass -File .\lab\windows-nginx-validation.ps1 python .\scripts\self_check.py ``` ## 防御性工作流 1. 盘点正在运行的 NGINX 版本。 2. 验证你的供应商是否向后移植（backport）了修复补丁。 3. 在当前生效的配置中搜索 regex `map` 块。 4. 审查捕获和 map 输出是否出现在后续的 string expression 中。 5. 升级补丁至 `1.30.4+` 或 `1.31.3+`，或相应的 NGINX Plus 已修复版本。 6. 重启或重新加载 worker，并确认实际运行的确实是已修复的二进制文件。 7. 在修补后，监控 worker 重启、请求突增以及 `no buffer space in script copy` 现象。 ## 信息来源 - NGINX 安全公告页面：https://nginx.org/en/security_advisories.html - NGINX 更新日志：https://nginx.org/en/CHANGES - NVD CVE 记录：https://nvd.nist.gov/vuln/detail/CVE-2026-42533 - Penligent 技术解释：https://www.penligent.ai/hackinglabs/cve-2026-42533/

标签：AI合规, DoS漏洞, NGINX, 漏洞审计, 负责任AI, 逆向工具, 配置扫描, 防御研究