引言
近日，GitHub 被曝出一个严重的安全漏洞，引发了广泛关注。开源安全软件公司 Truffle Security 的安全研究员 Joe Leon 发现，在 GitHub 上删除的代码仓库实际上仍然可以被访问。这一发现震惊了整个开源社区。本文将详细探讨这一安全漏洞的发现过程、其技术细节及其对 GitHub 用户的影响。
发现过程
在 Joe Leon 的研究中，他发现当用户在 GitHub 上删除一个 fork 的仓库时，实际上提交到该仓库的数据仍然可以被访问。这一问题的严重性在于，即便原始仓库被删除，fork 仓库的提交数据也仍然存在，且可以通过提交的哈希值来访问。
具体操作步骤
- 用户 fork 一个公共仓库。
- 用户向 fork 仓库提交数据。
- 用户删除 fork 仓库。
尽管用户认为这些数据已经被删除，但实际上仍可以通过原始仓库访问这些数据。这意味着，删除操作在数据保护方面实际上是无效的。
技术细节
GitHub 的这一问题源自于其处理删除仓库的方式。当用户删除一个仓库时，GitHub 只是删除了仓库的引用，但提交的数据仍然保存在其底层存储中。更令人担忧的是，任何人只要知道提交的哈希值，就可以访问这些提交的数据。
CFOR（Cross Fork Object Reference）漏洞
Truffle Security 引入了一个新的安全术语 CFOR（Cross Fork Object Reference）来描述这一漏洞。CFOR 意味着当一个仓库 fork 可以访问另一个 fork 中的敏感数据时，就会出现这种漏洞。用户只需要提供 commit 的哈希值，就可以直接访问提交的数据。
SHA-1哈希暴力破解
GitHub 允许使用短 SHA-1 值来引用提交，而短 SHA-1 值最小为 4 个字符。由于 4 个字符的 SHA-1 值只有 65,536 种可能性，这使得暴力破解这些值变得相对容易。一旦破解了哈希值，用户就可以访问到相关的提交数据。
案例研究
研究人员在一段视频中展示了如何利用这一漏洞。他们 fork 了一个仓库，提交数据后删除了 fork 仓库，结果仍然可以通过原始仓库访问“已删除”的数据。更令人担忧的是，研究人员在一家大型 AI 公司的 3 个经常被 fork 的公共代码仓库中，轻松找到了 40 个有效的 API 密钥。
GitHub 的回应
GitHub 将 CFOR 视为一种设计特性，而非漏洞。他们认为这是有意为之的设计，符合其预期。GitHub 的官方文档也描述了这种行为。这一回应引发了广泛争议，因为这种设计显然存在安全隐患。
平台的处理方式
虽然悬空提交是 git 中的一个概念，并不属于 GitHub 的功能，但每个平台对于悬空提交的处理方式是不同的。Bitbucket、GitLab 和 GitHub 都保留这些提交，只要用户掌握了标识符就可以访问这些数据。
影响和建议
这一安全漏洞对使用 GitHub 的企业和个人用户构成了严重的安全隐患。他们的机密数据可能会无意中暴露在组织的公共 GitHub 仓库中。为了防止数据泄露，Truffle Security 建议用户在发现提交了敏感信息后，应立即更换密钥，而不是仅仅删除相关的仓库或引用。
总结
GitHub 的这一设计特性暴露了其在数据删除和保护方面的重大缺陷。尽管 GitHub 将其视为功能，但这一漏洞显然需要引起重视。希望 GitHub 能重新考虑其立场，为用户提供更安全的数据保护机制。
未来展望
未来，GitHub 或其他代码托管平台可能需要引入新的功能，以允许用户永久删除提交的数据，并确保 fork 之间的数据隔离。同时，用户在使用这些平台时也需要更加谨慎，避免提交敏感信息。
