报告 #1024749 - 因意外文件权限变更导致的Cookie泄露 | HackerOne

时间线

nyymi 向curl提交了一份报告 2020年11月2日 下午7:25 UTC

摘要：

自7.72.0版本起，libcurl将CURLOPT_COOKIEJAR指定的文件更改为组和全局可读，无论已存在文件的先前权限如何（假设典型的默认umask为022）。这是意外的，因为通常不会更改已存在文件的权限。实际上，此版本之前的libcurl按预期保持原始文件权限。

复现步骤：

1
2
3
4

install -m 600 /dev/null cookie.jar
ls -l cookie.jar
curl -s -c cookie.jar https://www.google.com -o /dev/null
ls -l cookie.jar

支持材料/参考：

此错误是作为 https://github.com/curl/curl/commit/b834890a3fa3f525cd8ef4e99554cdb4558d7e1b 的副作用引入的。

影响

存储在CURLOPT_COOKIEJAR（libcurl）或-c / –cookie-jar（curl命令行工具）文件中的机密信息泄露。

nyymi 发表了评论。 更新于2020年11月2日 下午7:47 UTC

如果文件已存在（并且没有执行命令的用户和组），文件的所有者和组发生变化也可能出乎意料。

我思考了应如何处理这个问题，不幸的是没有简单的方法来修复这个问题。

您可能认为这可以是一个修复（仅考虑文件已存在的情况）：

1. 对原始文件进行stat()并获取其模式
2. 使用模式0创建临时文件
3. 使用stat获取的所有者和组对打开的文件进行fchown()
4. 使用之前通过stat获取的模式进行fchmod()
5. 对文件描述符进行fdopen()

我认为，上述方法至少对特权用户有些作用。显然，对非特权用户不会正常工作。

nyymi 发表了评论。 2020年11月2日 下午8:08 UTC

当然，例如安全关键的脚本、守护进程等应以077的umask运行，从而消除此问题。

无论哪种方式，对已存在文件的行为变更都是意外的。

bagder curl员工 发表了评论。 2020年11月2日 下午9:34 UTC

我同意这可能出乎意料，并且可能有理由对其进行改进，但由于没有记录的行为，因此也没有保证的功能，我认为将此称为安全问题有些牵强。

nyymi 关闭了报告并将状态更改为不适用。 2020年11月3日 上午12:01 UTC

在项目范围内不被视为安全缺陷。

bagder curl员工 请求披露此报告。 11天前

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

bagder curl员工 披露了此报告。 11天前

报告详情