私有数据、删掉的内容可以永久访问,GitHub官方:故意设计的

发布日期: 2024年8月9日 来源:机器之心

最近,一个消息震惊开源社区:在 GitHub 上删掉的内容、私有存储库的数据都是可以永久访问的,而且这是官方故意设计的。

开源安全软件公司 Truffle Security 在一篇博客中详细描述了这个问题。

Truffle Security 引入了一个新术语:CFOR(Cross Fork Object Reference):当一个存储库 fork 可以访问另一个 fork 中的敏感数据(包括来自私有和已删除 fork 的数据)时,就会出现 CFOR 漏洞。

与不安全的直接对象引用类似,在 CFOR 中,用户提供提交(commit)哈希值就可以直接访问提交数据,否则这些数据是不可见的。

以下是 Truffle Security 博客原文内容。

访问已删除 fork 存储库的数据

想象如下工作流程:

  • 在 GitHub 上 fork 一个公共存储库;
  • 将代码提交到你的 fork 存储库中;
  • 你删除你的 fork 存储库。

那么,你提交给 fork 的代码应该是不能访问了对吧,因为你把 fork 存储库删除了。然而它却永久可以访问,不受你控制。

如下视频所示,fork 一个存储库,向其中提交数据,再删除 fork 存储库,那么可以通过原始存储库访问「已删除」的提交数据。

这种情况普遍存在。Truffle Security 调查了一家大型 AI 公司 3 个经常被 fork 的公共存储库,并从已删除的 fork 存储库中轻松找到了 40 个有效的 API 密钥。

访问已删除存储库的数据

考虑如下工作流程:

  • 你在 GitHub 上有一个公共存储库;
  • 用户 fork 你的存储库;
  • 你在他们 fork 后提交数据,并且他们从不将其 fork 存储库与你的更新同步;
  • 你删除整个存储库。

那么,用户 fork 你的存储库后你提交的代码仍然可以访问。

GitHub 将存储库和 fork 存储库储存在存储库网络中,原始「上游」存储库充当根节点。当已 fork 的公共「上游」存储库被「删除」时,GitHub 会将根节点角色重新分配给下游 fork 存储库之一。但是,来自「上游」存储库的所有提交仍然存在,并且可以通过任何 fork 存储库访问。

这种情况不是个例,上周就发生了这样一件事情:

Truffle Security 向一家大型科技公司提交了一个 P1 漏洞,显示他们意外地提交了一名员工 GitHub 帐户的密钥,而该帐户对整个 GitHub 机构拥有重要访问权限。该公司立即删除了存储库,但由于该存储库已被 fork,因此仍然可以通过 fork 存储库访问包含敏感数据的提交,尽管 fork 存储库从未与原始「上游」存储库同步。

也就是说,只要存储库有至少一个 fork 存储库,那么提交到公共存储库的任何代码都可以永久访问。

访问私有存储库数据

考虑如下工作流程:

  • 你创建一个最终将公开的私有存储库;
  • 创建该存储库的私有内部版本(通过 fork),并为不打算公开的特征提交额外的代码;
  • 你将你的「上游」存储库公开,并将你的 fork 存储库保持私有。

那么,私有特征和相关代码则可供公众查看。从你创建工具的内部 fork 存储库到开源该工具之间提交的任何代码,这些提交都可以通过公共存储库访问。

在你将「上游」存储库公开后,对你的私有 fork 存储库所做的任何提交都是不可见的。这是因为更改私有「上游」存储库的可见性会导致两个存储库网络:一个用于私有版本,一个用于公开版本。

不幸的是,该工作流程是用户和机构开发开源软件时最常用的方法之一。因此,机密数据可能会无意中暴露在 GitHub 公共存储库上。

如何访问数据?

GitHub 存储库网络中的破坏性操作(如上述 3 个场景)会从标准 GitHub UI 和正常 git 操作中删除提交数据的引用。但是,这些数据仍然存在并且可以访问(commit hash)。这是 CFOR 和 IDOR 漏洞之间的联系。

commit hash 可以通过 GitHub 的 UI 进行暴力破解,特别是因为 git 协议允许在引用提交时使用短 SHA-1 值。短 SHA-1 值是避免与另一个 commit hash 发生冲突所需的最小字符数,绝对最小值为 4。所有 4 个字符 SHA-1 值的密钥空间为 65536 (16^4)。暴力破解所有可能的值可以相对容易地实现。

有趣的是,GitHub 公开了一个公共事件 API 端点。你还可以在由第三方管理的事件存档中查询 commit hash,并将过去十年的所有 GitHub 事件保存在 GitHub 之外,即使在存储库被删除之后也是如此。

GitHub 的规定

Truffle Security 通过 GitHub 的 VDP 计划将其发现提交给了 GitHub 官方。GitHub 回应道:「这是故意设计的」,并附上了说明文档。

说明文档:https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility

Truffle Security 赞赏 GitHub 对其架构保持透明,但 Truffle Security 认为:普通用户将私有和公共存储库的分离视为安全边界,并且认为公共用户无法访问私有存储库中的任何数据。不幸的是,如上所述,情况并不总是如此。

Truffle Security 得出的结论是:只要一个 fork 存储库存在,对该存储库网络的任何提交(即「上游」存储库或「下游」fork 存储库上的提交)都将永久存在。

Truffle Security 还提出一种观点:安全修复公共 GitHub 存储库上泄露密钥的唯一方法是通过密钥轮换。

GitHub 的存储库架构存在这些设计缺陷。不幸的是,绝大多数 GitHub 用户永远不会理解存储库网络的实际工作原理,并且会因此而降低安全性。

原文链接:https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github