MJ-bin/POC_CVE-2026-45185

# CVE-2026-45185 Nuclei 模板验证实验室 本仓库并非通用漏洞利用 PoC 仓库。它是一个用于复现和审查 `CVE-2026-45185` 模板行为的本地验证实验室，该模板旨在贡献给 `projectdiscovery/nuclei-templates`。 ``` The nuclei code template is not a version-only detector. It directly controls STARTTLS, BDAT, TLS close_notify, and a following SMTP plaintext byte on the same TCP connection. This sequence matches in the local vulnerable Exim 4.99.2 GnuTLS lab and does not match in the patched Exim 4.99.3 GnuTLS lab under the same conditions. ``` 当前的验证信号是一个远程 SMTP 响应预言机，而非对 UAF 写入本身的直接观察。从内部机制看，此 CVE 是一个释放后使用 漏洞，其中换行符（`\r`/`\n`）在 TLS 关闭后可以被写入一个已释放的 GnuTLS 传输缓冲区。实际上，客户端无法现实地通过 SMTP 响应直接观察到该写入操作。因此，本文档和模板不声称能直接证明 `bdat_ungetc -> tls_ungetc` 的 UAF 写入或远程代码执行。相反，模板检测的是在触发流程中出现的接收栈/状态恢复差异。 在追踪漏洞机制时，我观察到在 STARTTLS + BDAT 处理期间发生 TLS `close_notify` 后，过时的 `tls_*` 函数指针可能会保留在 BDAT 接收栈的下层，而不是被正确恢复为 `smtp_*` 函数指针。这种状态在服务器处理下一个 SMTP 命令时变得可见。在拆分 BDAT 首次完成后，在同一会话上发送 `NOOP` 会导致易受攻击的 Exim 4.99.2 GnuTLS 实验室返回 `421 lost input connection`，而修补后的 Exim 4.99.3 GnuTLS 实验室会正常处理并返回 `250 OK`。这种明显的易受攻击/已修补响应差异被用作本地授权 nuclei 代码模板的匹配条件。 更深入的漏洞流程分析，请参见 `CVE-2026-45185-Technical-Analysis.md`。 ## 验证矩阵 | 目标 | 版本 | TLS 后端 | STARTTLS | CHUNKING | 端口 | 预期 nuclei 结果 | | --- | --- | --- | --- | --- | --- | --- | | 易受攻击版本 | Exim 4.99.2 | GnuTLS | 是 | 是 | `127.0.0.1:2525` | 匹配 | | 修补后版本 | Exim 4.99.3 | GnuTLS | 是 | 是 | `127.0.0.1:2526` | 不匹配 | 通用 SMTP 信封收件人（`RCPT TO`）： ``` victim@lab.local ``` Docker 实验室的 `lab_rcpt` ACL 接受此信封收件人。对于通用的 SMTP 目标，如果 `RCPT TO` 被拒绝，该流程可能无法到达 BDAT 正文解析器，因此模板需要一个被接受的收件人。 此值与 BDAT 正文内部的 `To:` 头不同。`RCPT TO` 收件人是 SMTP 信封地址，必须通过服务器的收件人检查。BDAT 正文中的 `To:` 值仅为消息头文本；它不需要存在，也不需要作为邮箱被服务器接受。 ## 模板位置 ``` templates/CVE-2026-45185.yaml ``` 模板名称： ``` Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Same-Session Response Check ``` 该模板以 `metadata.verified: true` 编写，并带有 `code` 和 `intrusive` 标签。 ## 快速验证 从 `POC_2026_45185/` 目录运行以下命令。 ``` docker compose build docker compose up -d ``` 验证模板语法： ``` nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml ``` 运行前签署本地代码模板： ``` nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign ``` 针对易受攻击的实验室运行： ``` nuclei -code \ -t templates/CVE-2026-45185.yaml \ -u 127.0.0.1:2525 \ -var recipient=victim@lab.local \ -debug ``` 预期结果： ``` CVE-2026-45185: vulnerable response oracle matched ``` 针对修补后的实验室运行： ``` nuclei -code \ -t templates/CVE-2026-45185.yaml \ -u 127.0.0.1:2526 \ -var recipient=victim@lab.local \ -debug ``` 预期结果： ``` no match NO-MATCH: patched-like response: NOOP succeeded after split trigger ``` 注意，nuclei 的 `code` 协议默认不执行，因此需要 `-code` 标志。Nuclei 也会阻止未签名的 `code` 模板。如果本地 nuclei 私钥受密码保护，请在交互式终端中运行签名命令并输入该密码。每次模板修改后都需重新签名，因为摘要覆盖了模板内容。 ## 示例 Nuclei 结果 这些截图显示了模板签署后的本地实验室响应预言机结果。它们是上文描述的同会话响应差异的验证证据，而非内部 UAF 写入的直接调试器或 ASAN 证明。 `127.0.0.1:2525` 上的易受攻击 Exim 4.99.2 GnuTLS 实验室：  `127.0.0.1:2526` 上的修补后 Exim 4.99.3 GnuTLS 实验室：  ## 为何使用代码协议？ 此 CVE 的核心不是 SMTP 横幅或版本检查。该模板需要在同一 TCP 连接上创建以下传输状态转换： ``` plaintext SMTP EHLO -> STARTTLS -> TLS handshake on the same TCP connection -> TLS EHLO / MAIL FROM / RCPT TO / BDAT 70 LAST -> first 69 bytes of the BDAT body as TLS application data -> TLS close_notify without closing the TCP socket -> final body byte as plaintext on the same TCP connection -> same-session plaintext NOOP response check ``` ## 模板检查内容 YAML 模板中的 Python 代码仅在以下所有条件通过后才打印固定标记。Nuclei 匹配器仅匹配该标记。 ``` Exim identity is found AND STARTTLS is advertised in plaintext EHLO AND CHUNKING is advertised in plaintext EHLO AND STARTTLS is accepted AND CHUNKING is advertised in TLS EHLO AND MAIL FROM is accepted AND RCPT TO is accepted AND the split close_notify BDAT reaches first completion AND first completion contains "250 OK id=" AND the same-session plaintext NOOP response contains "421" AND the same-session plaintext NOOP response contains "lost input connection" ``` 该模板不会单独匹配以下任何信号： ``` version-only timeout-only connection-drop-only empty-response-only recipient rejection STARTTLS/CHUNKING advertisement only ``` ## 响应预言机 两个实验室都通过首次完成来处理拆分的 BDAT 消息。 ``` 250- 70 byte chunk, total 72 250 OK id=... ``` 差异出现在下一个 SMTP 明文命令在同一 SMTP 会话上发送时。 易受攻击的 4.99.2 版本： ``` NOOP -> 421 exim-lab.local lost input connection QUIT -> 421 exim-lab.local lost input connection RSET -> 421 exim-lab.local lost input connection ``` 修补后的 4.99.3 版本： ``` NOOP -> 250 OK QUIT -> 221 exim-lab.local closing connection RSET -> 250 Reset OK ``` 解释： ``` Observation: Both labs reach split BDAT message completion. Only the vulnerable lab fails to return cleanly to the next plaintext SMTP command loop in the same session. Evidence: The vulnerable follow-up response is 421 lost input connection. The patched follow-up response is 250 OK or 221 closing connection. Inference: This difference is consistent with the receive stack/state recovery difference after STARTTLS close_notify. ``` ## 载荷结构 模板使用以下 70 字节的消息作为 BDAT 正文。 ``` From: sender@example.com\r\n To: victim@example.com\r\n Subject: poc\r\n \r\n body ``` SMTP 信封收件人通过模板变量 `recipient` 单独传递。正文中的 `To:` 头是文本，与 SMTP `RCPT TO` 是否被接受无关，因此不需要存在或被服务器接受。 拆分结构： ``` BDAT 70 LAST TLS body: first 69 bytes, ending with "bod" TLS event: close_notify Plaintext: final byte "y" Follow-up: NOOP ``` ## 本地健全性检查 您可以手动验证两个实验室是否都宣传了 Exim、STARTTLS 和 CHUNKING。 ``` printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2525 printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2526 ``` 预期信号： ``` Exim STARTTLS CHUNKING ``` 您也可以检查正常的 STARTTLS 路径： ``` openssl s_client -starttls smtp -connect 127.0.0.1:2525 -crlf openssl s_client -starttls smtp -connect 127.0.0.1:2526 -crlf ``` ## 范围与安全性 - 仅针对本地 Docker 实验室或明确授权的 SMTP 目标使用此工具。 - 请勿扫描或向第三方 Exim 服务器发送触发数据。 - 本仓库不提供 RCE 漏洞利用链、持久化或后渗透能力。 - 默认的 Docker 镜像是调试版本，而非 ASAN 版本。 - 用于内部调用路径确认的后续 gdb/ASAN 工作在 `debugging/` 和 `notes/source-walkthrough-progress.md` 中单独跟踪。 ## 仓库布局 ``` POC_2026_45185/ compose.yaml images/ local nuclei validation screenshots vulnerable/ Exim 4.99.2 + GnuTLS debug build patched/ Exim 4.99.3 + GnuTLS debug build nuclei-templates/ submodule: local nuclei template workspace ``` ## 参考资料 - XBOW 分析报告：https://xbow.com/blog/dead-letter-cve-2026-45185-xbow-found-rce-exim - NVD：https://nvd.nist.gov/vuln/detail/CVE-2026-45185 - Exim 安全公告：https://exim.org/static/doc/security/EXIM-Security-2026-05-01.1/EXIM-Security-2026-05-01.1.txt - oss-security 公告：https://www.openwall.com/lists/oss-security/2026/05/12/4 - 上游 Exim 补丁：https://code.exim.org/exim/exim/commit/040c1ce6889f435206677ed532c9a4185cf0bcaf

标签：BDAT协议, CVE-2026-45185, Exim服务器, GnuTLS, Google, Nuclei, SMTP响应分析, SMTP漏洞, STARTTLS, TLS安全, 安全模板, 情报收集, 本地验证实验室, 模板验证, 漏洞研究, 编程工具, 网络安全, 请求拦截, 远程代码执行, 逆向工具, 释放后使用漏洞, 隐私保护