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

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

点击访问我的技术博客https://ai.weoknow.comhttps://ai.weoknow.com

开源安全软件公司 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 存储库，那么可以通过原始存储库访问「已删除」的提交数据。

，时长00:55

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

访问已删除存储库的数据

考虑如下工作流程：

• 你在 GitHub 上有一个公共存储库；

• 用户 fork 你的存储库；

• 你在他们 fork 后提交数据，并且他们从不将其 fork 存储库与你的更新同步；

• 你删除整个存储库。

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

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

，时长01:22

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

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

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

访问私有存储库数据

考虑如下工作流程：

• 你创建一个最终将公开的私有存储库；

• 创建该存储库的私有内部版本（通过 fork），并为不打算公开的特征提交额外的代码；

• 你将你的「上游」存储库公开，并将你的 fork 存储库保持私有。

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

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

，时长01:19

不幸的是，该工作流程是用户和机构开发开源软件时最常用的方法之一。因此，机密数据可能会无意中暴露在 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://ai.weoknow.comhttps://ai.weoknow.com