我们正处于一个信息大暴发的时代,每天都能产生数以百万计的新闻资讯!
虽然有大数据推荐,但面对海量数据,通过我们的调研发现,在一个小时的时间里,您通常无法真正有效地获取您感兴趣的资讯!
头条新闻资讯订阅,旨在帮助您收集感兴趣的资讯内容,并且在第一时间通知到您。可以有效节约您获取资讯的时间,避免错过一些关键信息。
最近,一个消息震惊开源社区:在 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返回搜狐,查看更多
以上内容为资讯信息快照,由td.fyun.cc爬虫进行采集并收录,本站未对信息做任何修改,信息内容不代表本站立场。
快照生成时间:2024-07-30 12:45:01
本站信息快照查询为非营利公共服务,如有侵权请联系我们进行删除。
信息原文地址: