curl持久化文件权限漏洞分析：Cookie/HSTS/Alt-Svc缓存泄露风险

执行摘要

Curl_fopen()在创建临时文件时会克隆任何已存在持久化文件的权限。当持久化文件不存在时，它会首先使用进程umask（通常为022，即0644）创建一个文件。该模式随后通过0600 | sb.st_mode复制到临时文件，因此最终的cookie/HSTS/Alt-Svc存储最终会变成组/其他用户可读，即使它包含承载令牌。（lib/curl_fopen.c:101-150）

所有依赖Curl_fopen()的有状态持久化功能——cookie_output()、Curl_hsts_save()和Curl_altsvc_save()——都继承了此行为，将会话cookie、HSTS缓存条目和Alt-Svc元数据泄露给任何本地用户。

复现步骤

环境：macOS 26.1 Dev Beta 4，提交a49e4e3d16991465144558f405b2d7972824abb0，使用./configure --disable-shared --with-openssl=/opt/homebrew/opt/openssl@3 --without-libpsl && make -j8构建。

确保没有残留文件并模拟正常的多用户umask：

1
2
3


rm -f /tmp/cookie-leak.txt && umask 022 \
&& ./src/curl -s -o /dev/null -c /tmp/cookie-leak.txt https://example.org \
&& ls -l /tmp/cookie-leak.txt

输出：.rw-r--r-- 131 geeknik 26 Oct 22:22 /tmp/cookie-leak.txt

即使没有设置任何cookie，cookie jar也会被创建，这足以演示默认的0644模式。

作为另一个本地用户，只需cat /tmp/cookie-leak.txt即可读取文件内容——在实际流量中完整的会话cookie将被暴露。相同的复现方法适用于--hsts和--alt-svc文件，因为它们调用Curl_fopen()的代码路径相同。

此外，我们还在Fedora上使用curl 8.6.0（x86_64-redhat-linux-gnu）复现了此行为。

CVSS v3.0

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

建议修复

将第140-141行替换为：

1

fd = curlx_open(tempstore, O_WRONLY | O_CREAT | O_EXCL, 0600);

影响

同一主机上的任何本地用户（共享CI运行器、大学shell、托管桌面等）可以读取另一个用户的curl/libcurl客户端写入的身份验证cookie、会话令牌、CSRF nonce、HSTS预加载数据或Alt-Svc目标。直接后果范围从完全账户接管（cookie重放）到绕过HSTS（通过在受害者读取文件前重写文件）以及对Alt-Svc缓存中列出的内部端点进行情报收集。由于这些文件在使用CURLOPT_COOKIEJAR、CURLOPT_HSTSWRITEFUNCTION或CURLOPT_ALTSVC时会自动写入，即使是配置良好的自动化也会无意中将秘密泄露给共同驻留的用户。

讨论记录

geeknik提交报告，指出curl持久化文件权限问题。

bagder (curl工作人员) 回应：如果用户希望创建的文件受到保护，为什么他们会设置允许其他用户读/写创建文件的umask？这似乎正是umask的用途。

jimfuller2024 (curl工作人员) 回应：没有看到任何安全问题，更多信息可能有助于澄清。

geeknik进一步解释：

curl已经对凭据进行特殊处理
大多数系统上的默认行为是不安全的
最小意外原则
现实世界自动化陷阱
行业先例

bagder质疑关于.netrc文件的说法，认为这是虚构内容。

geeknik关闭报告并将状态改为"不适用"，承认对.netrc文件的理解有误。

bagder道歉并请求披露此报告，遵循项目透明度政策。

bagder披露此报告。