CVE-2021-40438_ Apache HTTP Server mod_proxy 模块 SSRF漏洞

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

1. 用户访问http://yoursite/app/users

mod_proxy_http的canon handler把这个请求规范化：

原始：/app/users 规范化后：proxy:http://backend:8080/api/users

2. 这个标准化的字符串保存到r->filename
3. 后面的代理逻辑看到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