CVE-2021-40438_ Apache HTTP Server mod_proxy 模块 SSRF漏洞
- [1. 漏洞原理](#1. 漏洞原理)
-
- [mod_proxy 架构](#mod_proxy 架构)
- 漏洞怎么发生的？
- [2. 漏洞危害](#2. 漏洞危害)
- [3. 漏洞修复](#3. 漏洞修复)
CVSS评分：9.0
1. 漏洞原理
漏洞详细分析：
- https://firzen.de/building-a-poc-for-cve-2021-40438
- https://www.leavesongs.com/PENETRATION/apache-mod-proxy-ssrf-cve-2021-40438.html
mod_proxy 架构
简单说说mod_proxy 架构：mod_proxy 是一个框架，具体协议由 mod_proxy_http、mod_proxy_fcgi、mod_proxy_ajp 等子模块实现。每个子模块会注册自己的 canon handler 来把配置或请求 URL 规范化，最终生成 r->filename 这样的中间表示（以 proxy: 开头的字符串），供后续代理逻辑使用。
举个例子，假设配置是：
bash
ProxyPass /app http://backend:8080/api- 用户访问
http://yoursite/app/users
mod_proxy_http的canon handler把这个请求规范化：
plain
原始：/app/users
规范化后：proxy:http://backend:8080/api/users- 这个标准化的字符串保存到
r->filename - 后面的代理逻辑看到
proxy:开头的内容，就知道：
- 这是个代理请求
- 具体由哪个子模块处理（根据协议类型）
漏洞怎么发生的？
Apache 支持一种 "unix socket + 后端 URL" 的混合写法（例如 unix:/path/to.sock|http://...）------这是用于把反代指向本地 UDS 的便利语法。解析步骤里有个 fix_uds_filename 函数负责把 unix: 部分解析成 uds_path，把 | 之后的部分当作真实目标 URL
但是，r->filename 的后半段（path/search）来源于 HTTP 请求中的 path/query，而不是仅来源于静态配置，因此攻击者能在请求中插入操控内容，影响 r->filename 的最终字符串
fix_uds_filename 在把 unix: 的 path 变成 uds_path 时，会调用 ap_runtime_dir_relative → 最终走到 apr_filepath_merge。当 apr_filepath_merge 因入参超长或其他条件返回错误时，会导致 ap_runtime_dir_relative 返回 NULL，uds_path 未被正确设置，从而使代理逻辑走回"以 TCP/域名/URI 连接"的分支，使用 | 之后的那个 URL 作为目标------这就给了攻击者控制代理目标的机会。
2. 漏洞危害
借助该 SSRF，攻击者可访问内部网络服务，窃取敏感信息等等
该漏洞并非只能发 HTTP 请求，其能力取决于 Apache mod_proxy 当前加载了哪些 "scheme handler" 模块。
如果服务器加载了其它 proxy 扩展模块，则此 SSRF 就能支持更多的协议。
3. 漏洞修复
目前厂商已发布升级补丁以修复漏洞，补丁获取链接：