报告 #3445174 - file://协议路径遍历漏洞导致任意文件读取

时间线

• quello_stanco 向curl提交了一份报告。5天前

摘要

curl中的file://协议处理器未能正确清理或阻止路径遍历序列(../)。这使得恶意构造的file:// URL能够突破预期目录的限制，并以运行curl的用户的权限访问文件系统中的任意文件。

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

本报告的发现与生成未使用任何人工智能。

受影响版本

此漏洞在最新的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:// 处理程序强制执行的安全边界，使任何将其用于本地文件访问的应用程序都可能成为导致服务器信息完全泄露的潜在途径。

附件

• curl-poc.png (F5062021)

后续讨论

quello_stanco 发表评论。 5天前

团队您好，

根据我的初步报告，我发现了file://路径处理中一个额外的有趣行为，进一步证明了清理逻辑的薄弱点。

发现： 路径遍历清理程序错误地处理了双斜杠 (//)。

复现步骤： 运行以下命令：

1

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

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

分析： 看起来在处理完第一个 ..// 序列（正确地将 /some/random/path 解析为 /some/）之后，清理程序停止了处理后续的 ..// 序列。然后它错误地附加了路径的最后部分 (etc/passwd)。

虽然不如主要的路径遍历问题严重，但这证明了规范化逻辑中的一个缺陷，可能被用来绕过简单的过滤器，并进一步加强了彻底改进 file:// 路径处理的必要性。

谢谢。

bagder (curl 员工) 发表评论。 4天前 用户也可以直接访问该路径。curl 和用户拥有直接的文件访问权限。../ 移除功能并不为用户提供对 file:// 的保护。

bagder (curl 员工) 发表评论。 4天前 ./src/curl "file:///any/dummy/path/../../../../../../etc/passwd" 此路径被curl标准化为 /etc/passwd。

bagder (curl 员工) 发表评论。 4天前 file:///some/random/path/..//..//..//..//..//etc/ 此路径被curl标准化为 /some/random//etc/passwd。 我认为这里没有漏洞——这似乎是按预期工作的。

quello_stanco 发表评论。 4天前 嗨 Daniel，

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

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

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

我很快会将我的发现发布在这里。如果您能在我进行最后这项测试期间暂时将此报告保持打开状态，我将不胜感激。

再次感谢您的时间和考虑。

quello_stanco 发表评论。 4天前 您完全正确。

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

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

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

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

bagder (curl 员工) 关闭了报告并将状态更改为 不适用。 4天前 认为不是安全问题。

bagder (curl 员工) 请求公开此报告。 4天前 根据项目的透明性政策，我们希望所有报告都能被披露并公开。

bagder (curl 员工) 披露了此报告。 4天前

报告详情