GitHub 删除代码等于“任何人均可永久访问”！微软回应：我们有意为之

删除理论上意味着数据不再可访问，但实际上它变成了永久可访问，并且不受你控制。微软则坚称这是一个 feature，而非 bug。

普通用户将私有仓库和公共仓库的分离视为安全边界，并理所当然地认为位于私有仓库中的任何数据都无法被公共用户访问。不幸的是，在 GitHub 上，这并不总是正确的。此外，删除行为意味着数据的销毁。但实际上删除一个仓库或分叉并不意味着你提交数据真的被删除了。

Truffle Security 的研究人员们发现，已被删除的 GitHub 代码仓库（公开或私有）及仓库的已删除副本（分叉）仍有可能继续存在。

该公司安全研究员 Joe Leon 在本周三的一份咨询报告中表示，这种可能通过 API 密钥等方式继续访问已删除仓库中数据的情况属于安全风险。他还提出一条全新术语来描述这项漏洞，即跨分叉对象引用（CFOR）。

Leon 解释称，“所谓 CFOR 漏洞，是指某个代码仓库的分叉可以访问另一分叉的敏感数据（包括来自私有及已删除分叉的数据）。”

该公司还在示例展示了如何分叉代码仓库、向其提交数据、删除分叉，而后通过初始仓库访问名义上已被删除的提交数据。

研究人员还创建了一个代码仓库，对其进行了分叉，并展示了在删除初始仓库之后，未与分叉同步的数据如何继续通过分叉实现数据访问。

这些说法在论坛和社交媒体上引发了激烈的讨论，不少人呼吁 Github 采取行动。一位网友对此有一个比较浅显易懂的解释：“你分叉了一个上游仓库，并将其设置为私有。在这个私有分叉中，你提交了一些不应该公开或见不得光的东西。为了掩盖这些过失，你删除了那个提交。然而，现在看来，这些提交仍然可以轻易从上游仓库中访问到。”

根据 Leon 的介绍，这种情况源自上周他们向一家大型科技企业提交的严重漏洞报告。这份报告涉及员工 GitHub 账户的私钥，该账户在整个组织内拥有广泛的访问权限。目前此密钥已被公开提交至某 GitHub 代码仓库。在获悉这一失误后，该科技公司删除了相应仓库，并认为这样可以解决暴露问题。

Leon 解释称，“他们立即删除了代码仓库，但由于该仓库已被分叉，哪怕该分叉从未与初始「上游」仓库进行过同步，我也仍然可以通过分叉访问到包含敏感数据的提交。”

Leon 还补充道，在审查了多家大型 AI 公司的三个广泛分叉的公共代码仓库后，Truffle Security 的研究人员总计从已删除的分叉中找到了 40 个仍然有效的 API 密钥。

微软表示这是“有意为之”

这当然是个问题，但 GitHub 却将 CFOR 视为合法机制，并不是什么大问题。事实上，这家微软旗下的代码托管巨头将其归类为一项 feature，而非 bug。

在通过漏洞披露计划获悉这一情况时，GitHub 方面的回应是：“这是一项有意为之的设计，而且根据我们官方文档中的描述，其效果也完全符合预期。”

很明显，这个问题多年来一直为人所知。早在 2018 年就曾有个人向 GitHub 通报过该漏洞，也同样收到了类似的回复。

在电话采访中，Truffle Security 公司联合创始人兼 CEO Dylan Ayrey 解释称，这个问题属于所谓“悬空提交”。

“悬空提交是 git 创造出来的概念，并不属于 GitHub 的初始功能。具体来讲，悬空提交可以存在于任何 git 平台当中——Gitbucket、GitLab、GitHub 等等。悬空提交基本上存在于任何给定的代码仓库当中，也就是项目的历史记录会以树状结构存在，因此所有旧版本的代码都将彼此链接在一起。”

git 提交会捕捉代码仓库在特定时间点上的状态快照，包括对于代码和数据的变更。每次提交都由加密哈希提供唯一标识。例如，虽然删除分支会删除指向特定提交链的引用，但提交本身并不会被从仓库的对象数据库中删除。

Ayrey 指出，“因此悬空提交，就类似于 git 本身基础文档的组成部分。”各 git 平台对于悬空提交的处理方式由平台本身决定，而非受制于 git 规范。

Ayrey 还提到，即使与代码树之间的连接被切断，Bitbucket、GitLab 和 GitHub 也仍会保留这些提交。只要掌握能够直接访问这些内容的标识符，就仍可正常下载相关数据。

Ayrey 表示这个问题早已被公之于众。但在 GitHub 中，还存在一个与分叉（仓库副本）相关的特定近似问题。他解释称，分叉并不属于 git 规范的一部分，因此每种平台会采取各自不同的实现。

对于 GitHub，只要用户掌握标识哈希或者其中某一部分，即可通过分叉下载悬空提交。

“只要拥有标识符，就可以从作为初始推送目标的仓库处下载它们。事实证明，用户也可以通过该仓库的任意分支完成下载，而且这种开放是双向的。也就是说，我们可以从父级下载到分支中的悬空提交，也可以从分支下载到父级中的悬空提交。”

“我们发现即使删除了父提交，提交也仍会被正常推送，就是说悬空提交不仅仍然存在，而且允许通过子提交进行下载。哪怕父提交中的内容从未接触过子提交，并且已经在父提交侧被删除，也仍然可以访问到相应的悬空提交。”

此外，Ayrey 还提到用户甚至不需要完整的标识哈希即可访问悬空提交。“只要知晓标识符中的前四个字符，GitHub 基本就能自动补你补全标识符的剩余部分。”他还强调，这些字符只有 65000 种可能的组合，这个数字非常小，完全可能用暴力破解的方式来猜出。

在被问及这会带来哪些风险时，Ayrey 表示 GitHub 的一份事件归档记录了所有的公开 GitHub 操作。类似于阳光基金会的推文归档可以用于研究公开的社交媒体声明一样，GitHub 的事件归档也可用于对科技企业的所作所为进行取证调查。

“如果科技企业删除代码，特别是故意删除了某些内容——虽然不能说这背后就一定有什么问题，但多多少少会有其理由。这可能意味着密钥或者密码意外泄露，也可能是他们不小心上传了机器学习数据集。我们之前也见过这种情况。又或者，虽然比较少见，攻击者在他们的项目中设置了后门，所以大公司们想要避免尴尬……总之他们会删除仓库来掩盖问题。”

在被问及 GitHub 方面如何回应时，Ayrey 深思道：“如果某个平台制造了一个漏洞，将其记录下来，并解释称这是用户应当知晓并接受的风险，那这难道就能降低漏洞的危害性了？”

“如果我是 GitHub 的人，我可能会提议不在分叉之间共享这样的分叉池，确保推送至某一分叉的提交不可通过另一分叉进行下载。另外，我还会考虑提议建立新的功能，允许用户永久删除提交，而非使其处于悬空状态。”

“如果人们对此感到惊讶——显然有不少人感到惊讶——那么即使这种行为按预期工作，也应该在关键点的用户界面中加以提示。” 另一位说道。

Truffle Security 认为 GitHub 应该重新考虑自己在此事上的立场，毕竟普通用户还是希望在数据安全方面明确区分公共和私有仓库，包括认为删除操作应该能够将提交数据实际清理掉。

GitHub 公司一位发言人在采访中指出，“GitHub 致力于调查上报的安全问题。我们已经注意到此份报告，并确认这是由分叉网络工作方式所造成的、符合预期且在说明文档中做出了解释的固有行为。您可以在我们的官方文档中具体了解删除操作或者可见性变更，对于代码仓库分叉的实际影响。”

这事儿最后只剩下一个解决办法，那就是：更换你的密钥。

“如果你公开了一个密钥，你必须假设有人已经复制了它，删除相关引用是不够的，”一位 Hacker News 网友建议道。“你必须立即更换该密钥，并检查它是否被不当使用过。这是基本的事件响应措施。”

在 X 平台上，一位名叫 Mark O'Neill 的用户对他的 7000 名关注者说：“对不起，各位 CTO，我知道这周因为 CrowdStrike 事件已经很艰难了，但你们现在可能需要迅速更换所有的 API 密钥。”

参考链接：

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

https://www.theregister.com/2024/07/25/data_from_deleted_github_repos/

https://www.thestack.technology/github-repo-deleted/