报告 #3445174 - file://协议中的路径遍历导致任意文件读取 | HackerOne

时间线 quello_stanco 向 curl 提交了一份报告。3天前

摘要： curl 中的 file:// 协议处理程序未能正确清理或阻止路径遍历序列（../）。这允许恶意构造的 file:// URL 逃脱预期目录，并以运行 curl 的用户的权限访问文件系统上的任意文件。当 curl 被另一个处理用户提供的 URL 的应用程序（例如，Web 服务器后端）作为库使用时，这可能升级为远程、任意文件读取漏洞。 本报告的发现或生成未使用 AI。

受影响版本 该问题在最新的 master 分支上复现，提交 [c3add7130d7d81add205edbbb75fdfd1f38b3c68]。 curl -V 输出： 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 发布日期: [未发布] 协议: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss 特性: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets 平台: Debian GNU/Linux 13 (trixie ) 运行在 x86_64 上。

复现步骤：

从 master 分支克隆并构建最新版本的 curl。

从项目的根目录运行以下命令：

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 发表了评论。 3天前

你好团队，

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

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

复现步骤：

运行以下命令：

1

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

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

分析： 似乎在处理完第一个 ..// 序列（它正确地解析了 /some/random/path 到 /some/）之后，清理程序停止处理后续的 ..// 序列。然后它错误地附加了路径的最后部分（etc/passwd）。虽然没有主要路径遍历问题那么严重，但这表明了规范化逻辑中的一个缺陷，可能被用来绕过简单的过滤器，并进一步强化了彻底检修 file:// 路径处理的理由。谢谢。

bagder curl staff 发表了评论。 2天前用户同样可以直接访问该路径。curl 和用户拥有直接的文件访问权限。点号的移除并不能保护用户对于 file:// 协议的操作。

bagder curl staff 发表了评论。 2天前

1

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

此路径被 curl 规范化后变为 /etc/passwd。

bagder curl staff 发表了评论。 2天前

1

file:///some/random/path/..//..//..//..//..//etc/passwd

此路径被 curl 规范化后变为 /some/random//etc/passwd。我认为这里不存在漏洞 - 这似乎是按预期工作的。

quello_stanco 发表了评论。 2天前你好 Daniel，

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

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

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

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

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

quello_stanco 发表了评论。 2天前你完全正确。

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

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

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

你可以关闭这份报告了。我感谢这次对话。

bagder curl staff 关闭了报告并将状态更改为"不适用"。 2天前认为这不是一个安全问题。

bagder curl staff 请求公开此报告。 2天前根据项目透明度政策，我们希望所有报告都被公开并公之于众。

bagder curl staff 公开了此报告。 1天前

报告于 2025年11月30日，12:07am UTC 报告者 quello_stanco 报告给 curl 参与者 报告 ID #3445174 N/A 严重性 高 (7 ~ 8.9) 公开时间 2025年12月1日，7:41am UTC 弱点路径遍历 CVE ID 无赏金无 账户详情 无