最近，一個訊息震驚開源社群：在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}