Apache CVE-2021-41773：路径穿越的授权验证、配置边界与修复复测

发布于1小时前1小时

背景与适用范围

CVE-2021-41773 是 Apache HTTP Server 2.4.49 中的路径规范化缺陷。特定编码的路径可以绕过规范化检查，在受影响配置下访问 Alias 映射目录之外的文件。若相关目录同时允许 CGI 执行，还可能形成代码执行风险。本文只验证路径边界，不执行命令、不读取系统敏感文件。

需要区分两个漏洞：CVE-2021-41773 对应上游 2.4.49；2.4.50 的修复不完整，后续以 CVE-2021-42013 跟踪。上游 2.4.51 修复了这两个问题，但它也已经是历史版本，实际修复应升级到当前受支持的软件包，而不是停留在 2.4.51。

验证范围限于自有测试环境或书面授权的目标。不要通过读取 /etc/passwd、应用配置文件或云凭据证明漏洞；使用自行创建的标记文件即可。

具体场景与权限边界

假设站点存在静态资源映射：URL 前缀 /assets/ 对应文件系统目录 /srv/http/static/。预期权限边界是：客户端只能读取 static 目录内获准公开的资源，不能通过 URL 路径访问同级目录中的文件。

Alias "/assets/" "/srv/http/static/"

<Directory "/">
    AllowOverride None
    Require all denied
</Directory>

<Directory "/srv/http/static/">
    Options -Indexes -ExecCGI
    AllowOverride None
    Require all granted
</Directory>

上面的根目录拒绝规则是重要的纵深防护。路径规范化存在缺陷，不意味着所有部署都能读出目录外文件；目标目录的授权规则、文件权限以及代理行为都会影响结果。不要为了“复现成功”而在生产环境添加全局 Require all granted。

问题定位：确认真正处理请求的实例

先确认流量入口、监听进程、虚拟主机和生效配置。Server 响应头可能被隐藏、改写，不能作为唯一版本依据。容器内 Apache、宿主机软件包以及反向代理也可能不是同一个实例。

# Debian/Ubuntu 常见命令；其他发行版通常使用 httpd
apache2ctl -v
apache2ctl -V
apache2ctl -S
apache2ctl -t -D DUMP_RUN_CFG

# 检查相关配置，同时注意 Include 引入的其他路径
grep -RniE 'Alias|ScriptAlias|Require|ExecCGI|AddHandler|SetHandler' \
  /etc/apache2 2>/dev/null

# Debian/Ubuntu：核对安装版本和发行版修复记录
dpkg-query -W apache2 apache2-bin
zgrep -iE 'CVE-2021-41773|CVE-2021-42013' \
  /usr/share/doc/apache2/changelog.Debian.gz

RHEL 系可使用 rpm -q httpd 和 rpm -q --changelog httpd 辅助核对。发行版可能回移补丁，不能只比较上游版本号；最终应以对应发行版安全公告和安装包修订号确认。变更日志未出现 CVE 编号，也不等于一定没有修复。

技术分析：编码路径如何跨过目录边界

问题出在路径规范化过程中对编码点号的处理。.％2e 中的百分号换成 ASCII 字符后，就是请求中的 .%2e；解码后它对应两个点号。受影响的处理逻辑未能在这一过程完整阻断父目录段，导致 Alias 后面的路径有机会越过预期目录。

但“路径越界”和“读取成功”是两层判断：前者涉及 URL 到文件系统路径的解析，后者还需要 Apache 目录授权和操作系统读取权限同时允许。测试报告应分别记录软件包是否受影响、恶意路径是否到达源站、目录外标记文件是否实际返回。

操作步骤：使用标记文件做最小验证

以下操作在隔离测试站点执行。假设 /assets/ 已映射到 /srv/http/static/。先放置一个目录内对照文件和一个目录外标记文件；目录外文件不能通过其他 Alias、软链接或应用路由公开访问。

# 在测试服务器执行；不要覆盖已有文件
TOKEN="apache-path-probe-$(date +%s)-$$"
NAME="boundary-${TOKEN}.txt"
sudo mkdir -p /srv/http/static
printf '%s\n' "$TOKEN" | sudo tee "/srv/http/static/$NAME" >/dev/null
printf '%s\n' "$TOKEN" | sudo tee "/srv/http/$NAME" >/dev/null
sudo chmod 0644 "/srv/http/static/$NAME" "/srv/http/$NAME"
printf 'TOKEN=%s\nNAME=%s\n' "$TOKEN" "$NAME"

在测试客户端设置上一步输出的 NAME，然后发起基线请求与边界请求。示例地址使用保留测试域名，请替换为已授权目标。--path-as-is 用于避免 curl 在发送前自行折叠路径；不要添加 -L，避免自动跳转掩盖实际响应来源。

BASE='
NAME='替换为上一步生成的文件名'

# 基线：确认站点、Alias 和目录内文件正常
curl --path-as-is -i "$BASE/assets/$NAME"

# CVE-2021-41773 的路径边界验证
curl --path-as-is -i "$BASE/assets/.%2e/$NAME"

基线返回预期标记，说明当前请求确实能够访问测试资源。
边界请求返回目录外标记，才构成该测试路径下的目录边界突破证据。需要排除同名资源由应用兜底路由返回的情况。
返回 403 可能是 Apache 授权规则或 WAF 阻断，不能据此宣称软件包已修复。
返回 404 可能与补丁、路径映射、代理规范化或文件位置有关，同样不能单独证明安全。
该请求只覆盖 CVE-2021-41773 的一种验证路径，不能用它判定 2.4.50 不受 CVE-2021-42013 影响。

如果前面还有 CDN、WAF 或反向代理，应关联入口和源站日志。在授权允许时，可以对照测试入口地址与源站，但必须保持相同的 Host、TLS SNI 和虚拟主机，避免实际测到默认站点。

日志留痕与排查

记录测试时间、源 IP、目标虚拟主机、完整请求路径、状态码和标记响应。Apache 常见访问日志格式中的 %r 会记录请求行，可用于检索编码路径；错误日志则有助于定位目录授权拒绝。

# Debian/Ubuntu 常见日志位置；容器环境还需检查标准输出
sudo grep -Ei '(\.%2e|%2e%2e|%252e|%%32%65)' \
  /var/log/apache2/access.log

sudo grep -Ei 'client denied|authorization|AH01630' \
  /var/log/apache2/error.log

这些表达式只是线索，不是完整检测规则。不同组件可能保留原始编码，也可能先解码再记日志；日志还可能已轮转。不能把“未检索到”写成“没有遭到利用”。如发现历史异常请求，应进一步核查访问时间段、响应字节数、CGI 配置、异常进程和文件变更，而不是仅按状态码判断影响。

风险与修复建议

优先安装发行版当前受支持的 Apache 安全更新，并确认实际服务或容器镜像已更新。升级后重启或重建对应实例，检查是否仍有旧实例接收流量。
保留根目录 Require all denied，仅对确有需要的目录授权。审查 Alias、ScriptAlias 及被包含配置中的宽泛放行规则。
不需要 CGI 的站点移除相应处理器和映射。仅设置 Options -ExecCGI 不能替代对 ScriptAlias、处理器配置及模块使用情况的完整审查。
限制 Apache 运行账户的文件读取范围，避免应用密钥、备份和数据库导出文件与公开资源共享宽泛权限。
WAF 编码路径拦截只能作为临时缓解。规则可能存在解码差异，也无法修复源站的目录解析缺陷。

修复后重复基线和边界测试：公开资源应正常访问，目录外标记不应返回。同时核对软件包修订号、运行实例和源站日志。最后删除两个测试文件，并保存脱敏后的请求与响应证据。

总结

这类漏洞的验证重点不是“收到一个 200”，而是证明 URL 路径是否跨越了指定文件系统边界。漏洞库记录至少应包含受影响版本依据、生效配置、最小标记验证、日志证据和修复复测结果。把版本缺陷、配置缓解和真实读取能力分开描述，结论才可复核，也便于后续排查同类部署。

登录