报告 #3445174 - file://协议中的路径遍历允许任意文件读取

报告者：quello_stanco 提交给：curl 提交时间：10天前

摘要

cURL中的file://协议处理程序没有正确清理或阻止路径遍历序列（../）。这使得恶意构造的file:// URL能够逃离预期目录，并访问文件系统中运行cURL的用户权限范围内的任意文件。

当cURL被其他处理用户提供的URL的应用程序（例如，Web服务器后端）作为库使用时，这可能会升级为远程、任意文件读取漏洞。

本报告中未使用AI来发现此问题或生成报告。

受影响版本

此问题在最新的master分支（提交 [c3add7130d7d81add205edbbb75fdfd1f38b3c68]）上复现。

curl -V 输出：

1
2
3
4

curl 8.18.0-DEV (x86_64-pc-linux-gnu) libcurl/8.18.0-DEV OpenSSL/3.5.4 zlib/1.3.1 libpsl/0.21.2
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

平台：在 x86_64 上运行的 Debian GNU/Linux 13 (trixie)。

复现步骤

1. 从master分支克隆并构建最新版本的cURL。
2. 从项目的根目录运行以下命令：

   1	./src/curl "file:///any/dummy/path/../../../../../../etc/passwd"

   • 预期结果：cURL应该失败并报错，提示文件未找到或路径无效，因为它应该清理../序列。
   • 实际结果：cURL成功遍历到上层目录，并将/etc/passwd文件的内容打印到标准输出。

附加材料/参考

一张终端输出的截图已附加。

影响

此路径遍历漏洞允许任意文件读取。虽然直接在命令行上由用户运行的影响有限，但当libcurl被另一个从不受信任的用户输入构造file:// URL的应用程序使用时，其影响将变为高或严重。

远程攻击者可利用此漏洞：

• 读取包含数据库凭证、API密钥等的敏感配置文件（例如，config.php、.env）。
• 读取应用程序源代码以发现其他漏洞。
• 读取系统文件，如/etc/passwd、/etc/shadow（如果以足够的权限运行）。
• 读取私有SSH密钥或其他敏感用户数据。

这破坏了file://处理程序本应强制执行的安全边界，使得任何将其用于本地文件访问的应用程序都可能成为导致服务器信息完全泄露的潜在攻击向量。

附件：1个附件

• F5062021：curl-poc.png

讨论时间线

报告者 (quello_stanco) 发布的评论 - 10天前

团队您好， 根据我的初始报告，我在file://路径处理中发现了更多有趣的行为，这进一步证明了清理逻辑的弱点。

发现：路径遍历清理器对双斜杠（//）的处理不正确。

复现步骤：

1. 运行以下命令：

   1	./src/curl -v "file:///some/random/path/..//..//..//..//..//etc/passwd"

   • 实际结果：cURL尝试打开文件/some//etc/passwd。

分析： 在处理完第一个..//序列（它将/some/random/path正确解析为/some/）后，清理器似乎停止处理后续的..//序列。然后它错误地追加了路径的最终部分（etc/passwd）。

虽然这不像主要的路径遍历问题那么严重，但这表明了规范化逻辑中的一个缺陷，该缺陷可用于绕过简单的过滤器，并进一步强化了对file://路径处理进行彻底检修的理由。

谢谢。

cURL 团队成员 (bagder) 发布的评论 - 10天前

用户同样可以直接访问该路径。cURL和用户都拥有直接的文件访问权限。点号（..）删除并不能保护用户免受file://协议的影响。

cURL 团队成员 (bagder) 发布的评论 - 10天前

./src/curl "file:///any/dummy/path/../../../../../../etc/passwd" 此路径被cURL规范化为/etc/passwd。

cURL 团队成员 (bagder) 发布的评论 - 10天前

file:///some/random/path/..//..//..//..//..//etc/ 此路径被cURL规范化为/some/random//etc/passwd。 我认为这里不存在漏洞——这似乎是预期行为。

报告者 (quello_stanco) 回复 - 10天前

嗨，Daniel， 感谢您快速而清晰的解释。我理解您关于file://协议按预期行为的观点，即cURL充当用户本地文件访问权限的直接代理。

您的推理是有道理的。然而，我怀疑这种路径规范化行为在应用于远程网络协议时可能会产生意想不到的安全影响，在这些协议中，应由服务器而非用户来强制执行路径限制。

我目前正在设置一个本地FTP服务器，以测试相同的../遍历是否允许逃逸FTP用户的根目录。如果确实如此，这将证明可以绕过服务器端的安全边界，这与本地file://访问的场景不同。

我很快就会在此发布我的发现。如果您能在我进行最终测试期间暂时保持此报告开放，我将不胜感激。

再次感谢您抽出时间考虑。

报告者 (quello_stanco) 最终回复 - 10天前

您完全正确。

我已经完成了针对配置了chroot监禁的本地vsftpd服务器的测试。正如您所预测的，路径遍历被FTP服务器正确阻止，cURL也按预期运行，拒绝了目录更改。

这证实了您的评估，即路径规范化行为特定于file://处理程序，不会延续到执行服务器端安全措施的远程协议。

感谢您花时间解释设计理念。我在漏洞评估的上下文方面学到了宝贵的一课。我同意这不是一个漏洞。

您可以关闭此报告。感谢这次对话。

cURL 团队成员 (bagder) 关闭报告 - 10天前

状态更改为：不适用 被认为不是安全问题。

cURL 团队成员 (bagder) 请求披露 - 10天前

根据项目的透明度政策，我们希望所有报告都被披露并公开。

cURL 团队成员 (bagder) 披露报告 - 9天前

报告详情

• 报告日期：2025年11月30日，UTC时间 12:07am
• 报告者：quello_stanco
• 报告给：curl
• 报告ID：#3445174
• 严重性：高 (7 ~ 8.9)
• 披露日期：2025年12月1日，UTC时间 7:41am
• 弱点：路径遍历
• CVE ID：无
• 赏金：无
• 账户详情：无