CVE-2021-40438_ Apache HTTP Server mod_proxy 模块 SSRF漏洞
CVE-2021-40438_ Apache HTTP Server mod_proxy 模块 SSRF漏洞
- 1. 漏洞原理
- mod_proxy 架构
- 漏洞怎么发生的？
- 2. 漏洞危害
- 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:开头的字符串），供后续代理逻辑使用。
举个例子，假设配置是：
ProxyPass /app http://backend:8080/api- 用户访问
http://yoursite/app/users
mod_proxy_http的canon handler把这个请求规范化：
原始：/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. 漏洞修复
目前厂商已发布升级补丁以修复漏洞，补丁获取链接：
https://access.redhat.com/security/cve/cve-2021-40438