最近，一个消息震惊开源社区：在GitHub上删掉的内容、私有存储库的数据都是可以永久访问的，而且这是官方故意设计的。开源安全软件公司TruffleSecurity在一篇博客中详细描述了这个问题。
TruffleSecurity引入了一个新术语：CFOR（CrossForkObjectReference）：当一个存储库fork可以访问另一个fork中的敏感数据（包括来自私有和已删除fork的数据）时，就会出现CFOR漏洞。
与不安全的直接对象引用类似，在CFOR中，用户提供提交（commit）哈希值就可以直接访问提交数据，否则这些数据是不可见的。
以下是TruffleSecurity博客原文内容。
想象如下工作流程：
在GitHub上fork一个公共存储库；
将代码提交到你的fork存储库中；
你删除你的fork存储库。
那么，你提交给fork的代码应该是不能访问了对吧，因为你把fork存储库删除了。然而它却永久可以访问，不受你控制。
如下视频所示，fork一个存储库，向其中提交数据，再删除fork存储库，那么可以通过原始存储库访问“已删除”的提交数据。
这种情况普遍存在。TruffleSecurity调查了一家大型AI公司3个经常被fork的公共存储库，并从已删除的fork存储库中轻松找到了40个有效的API密钥。
考虑如下工作流程：
你在GitHub上有一个公共存储库；
用户fork你的存储库；
你在他们fork后提交数据，并且他们从不将其fork存储库与你的更新同步；
你删除整个存储库。
那么，用户fork你的存储库后你提交的代码仍然可以访问。
GitHub将存储库和fork存储库储存在存储库网络中，原始“上游”存储库充当根节点。当已fork的公共“上游”存储库被“删除”时，GitHub会将根节点角色重新分配给下游fork存储库之一。但是，来自“上游”存储库的所有提交仍然存在，并且可以通过任何fork存储库访问。
这种情况不是个例，上周就发生了这样一件事情：
TruffleSecurity向一家大型科技公司提交了一个P1漏洞，显示他们意外地提交了一名员工GitHub帐户的密钥，而该帐户对整个GitHub机构拥有重要访问权限。该公司立即删除了存储库，但由于该存储库已被fork，因此仍然可以通过fork存储库访问包含敏感数据的提交，尽管fork存储库从未与原始“上游”存储库同步。
也就是说，只要存储库有至少一个fork存储库，那么提交到公共存储库的任何代码都可以永久访问。
访问私有存储库数据
考虑如下工作流程：
你创建一个最终将公开的私有存储库；
创建该存储库的私有内部版本（通过fork），并为不打算公开的特征提交额外的代码；
你将你的“上游”存储库公开，并将你的fork存储库保持私有。
那么，私有特征和相关代码则可供公众查看。从你创建工具的内部fork存储库到开源该工具之间提交的任何代码，这些提交都可以通过公共存储库访问。
在你将“上游”存储库公开后，对你的私有fork存储库所做的任何提交都是不可见的。这是因为更改私有“上游”存储库的可见性会导致两个存储库网络：一个用于私有版本，一个用于公开版本。
不幸的是，该工作流程是用户和机构开发开源软件时最常用的方法之一。因此，机密数据可能会无意中暴露在GitHub公共存储库上。
GitHub存储库网络中的破坏性操作（如上述3个场景）会从标准GitHubUI和正常git操作中删除提交数据的引用。但是，这些数据仍然存在并且可以访问（commithash）。这是CFOR和IDOR漏洞之间的联系。
commithash可以通过GitHub的UI进行暴力破解，特别是因为git协议允许在引用提交时使用短SHA-1值。短SHA-1值是避免与另一个commithash发生冲突所需的最小字符数，绝对最小值为4。所有4个字符SHA-1值的密钥空间为65536(16^4)。暴力破解所有可能的值可以相对容易地实现。
有趣的是，GitHub公开了一个公共事件API端点。你还可以在由第三方管理的事件存档中
GitHub的规定
TruffleSecurity通过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
TruffleSecurity赞赏GitHub对其架构保持透明，但TruffleSecurity认为：普通用户将私有和公共存储库的分离视为安全边界，并且认为公共用户无法访问私有存储库中的任何数据。不幸的是，如上所述，情况并不总是如此。
TruffleSecurity得出的结论是：只要一个fork存储库存在，对该存储库网络的任何提交（即“上游”存储库或“下游”fork存储库上的提交）都将永久存在。
TruffleSecurity还提出一种观点：安全修复公共GitHub存储库上泄露密钥的唯一方法是通过密钥轮换。
GitHub的存储库架构存在这些设计缺陷。不幸的是，绝大多数GitHub用户永远不会理解存储库网络的实际工作原理，并且会因此而降低安全性。
相关文章
头条焦点
精彩导读
关注我们
【查看完整讨论话题】 | 【用户登录】 | 【用户注册】