最近，一個消息震驚開源社區(qū)：在 hub 上刪掉的內(nèi)容、私有存儲庫的數(shù)據(jù)都是可以永久訪問的，而且這是官方故意設(shè)計(jì)的。
開源安全軟件公司 Truffle Security 在一篇博客中詳細(xì)描述了這個問題。
Truffle Security 引入了一個新術(shù)語：CFOR（Cross Fork Object Reference）：當(dāng)一個存儲庫 fork 可以訪問另一個 fork 中的（包括來自私有和已刪除 fork 的數(shù)據(jù)）時，就會出現(xiàn) CFOR 漏洞。
與不安全的直接對象引用類似，在 CFOR 中，用戶提供提交（commit）哈希值就可以直接訪問提交數(shù)據(jù)，否則這些數(shù)據(jù)是不可見的。
以下是 Truffle Security 博客原文內(nèi)容。
訪問已刪除 fork 存儲庫的數(shù)據(jù)
想象如下工作流程：
-
在 GitHub 上 fork 一個公共存儲庫；
-
將代碼提交到你的 fork 存儲庫中；
-
你刪除你的 fork 存儲庫。
那么，你提交給 fork 的代碼應(yīng)該是不能訪問了對吧，因?yàn)槟惆?fork 存儲庫刪除了。然而它卻永久可以訪問，不受你控制。
如下視頻所示，fork 一個存儲庫，向其中提交數(shù)據(jù)，再刪除 fork 存儲庫，那么可以通過原始存儲庫訪問「已刪除」的提交數(shù)據(jù)。
這種情況普遍存在。Truffle Security 調(diào)查了一家大型 AI 公司 3 個經(jīng)常被 fork 的公共存儲庫，并從已刪除的 fork 存儲庫中輕松找到了 40 個有效的 API 密鑰。
訪問已刪除存儲庫的數(shù)據(jù)
考慮如下工作流程：
-
你在 GitHub 上有一個公共存儲庫；
-
用戶 fork 你的存儲庫；
-
你在他們 fork 后提交數(shù)據(jù)，并且他們從不將其 fork 存儲庫與你的更新同步；
-
你刪除整個存儲庫。
那么，用戶 fork 你的存儲庫后你提交的代碼仍然可以訪問。
GitHub 將存儲庫和 fork 存儲庫儲存在存儲庫網(wǎng)絡(luò)中，原始「上游」存儲庫充當(dāng)根節(jié)點(diǎn)。當(dāng)已 fork 的公共「上游」存儲庫被「刪除」時，GitHub 會將根節(jié)點(diǎn)角色重新分配給下游 fork 存儲庫之一。但是，來自「上游」存儲庫的所有提交仍然存在，并且可以通過任何 fork 存儲庫訪問。
這種情況不是個例，上周就發(fā)生了這樣一件事情：
Truffle Security 向一家大型科技公司提交了一個 P1 漏洞，顯示他們意外地提交了一名員工 GitHub 帳戶的密鑰，而該帳戶對整個 GitHub 機(jī)構(gòu)擁有重要訪問權(quán)限。該公司立即刪除了存儲庫，但由于該存儲庫已被 fork，因此仍然可以通過 fork 存儲庫訪問包含敏感數(shù)據(jù)的提交，盡管 fork 存儲庫從未與原始「上游」存儲庫同步。
也就是說，只要存儲庫有至少一個 fork 存儲庫，那么提交到公共存儲庫的任何代碼都可以永久訪問。
訪問私有存儲庫數(shù)據(jù)
考慮如下工作流程：
-
你創(chuàng)建一個最終將公開的私有存儲庫；
-
創(chuàng)建該存儲庫的私有內(nèi)部版本（通過 fork），并為不打算公開的特征提交額外的代碼；
-
你將你的「上游」存儲庫公開，并將你的 fork 存儲庫保持私有。
那么，私有特征和相關(guān)代碼則可供公眾查看。從你創(chuàng)建工具的內(nèi)部 fork 存儲庫到開源該工具之間提交的任何代碼，這些提交都可以通過公共存儲庫訪問。
在你將「上游」存儲庫公開后，對你的私有 fork 存儲庫所做的任何提交都是不可見的。這是因?yàn)楦乃接小干嫌巍勾鎯斓目梢娦詴?dǎo)致兩個存儲庫網(wǎng)絡(luò)：一個用于私有版本，一個用于公開版本。
不幸的是，該工作流程是用戶和機(jī)構(gòu)開發(fā)開源軟件時最常用的方法之一。因此，機(jī)密數(shù)據(jù)可能會無意中暴露在 GitHub 公共存儲庫上。
如何訪問數(shù)據(jù)？
GitHub 存儲庫網(wǎng)絡(luò)中的破壞性操作（如上述 3 個場景）會從標(biāo)準(zhǔn) GitHub UI 和正常 git 操作中刪除提交數(shù)據(jù)的引用。但是，這些數(shù)據(jù)仍然存在并且可以訪問（commit hash）。這是 CFOR 和 IDOR 漏洞之間的聯(lián)系。
commit hash 可以通過 GitHub 的 UI 進(jìn)行暴力破解，特別是因?yàn)?git 協(xié)議允許在引用提交時使用短 SHA-1 值。短 SHA-1 值是避免與另一個 commit hash 發(fā)生沖突所需的最小字符數(shù)，絕對最小值為 4。所有 4 個字符 SHA-1 值的密鑰空間為 65536 (16^4)。暴力破解所有可能的值可以相對容易地實(shí)現(xiàn)。
有趣的是，GitHub 公開了一個公共事件 API 端點(diǎn)。你還可以在由第三方管理的事件存檔中查詢 commit hash，并將過去十年的所有 GitHub 事件保存在 GitHub 之外，即使在存儲庫被刪除之后也是如此。
GitHub 的規(guī)定
Truffle Security 通過 GitHub 的 VDP 計(jì)劃將其發(fā)現(xiàn)提交給了 GitHub 官方。GitHub 回應(yīng)道：「這是故意設(shè)計(jì)的」，并附上了說明文檔。
說明文檔：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 對其架構(gòu)保持透明，但 Truffle Security 認(rèn)為：普通用戶將私有和公共存儲庫的分離視為安全邊界，并且認(rèn)為公共用戶無法訪問私有存儲庫中的任何數(shù)據(jù)。不幸的是，如上所述，情況并不總是如此。
Truffle Security 得出的結(jié)論是：只要一個 fork 存儲庫存在，對該存儲庫網(wǎng)絡(luò)的任何提交（即「上游」存儲庫或「下游」fork 存儲庫上的提交）都將永久存在。
Truffle Security 還提出一種觀點(diǎn)：安全修復(fù)公共 GitHub 存儲庫上泄露密鑰的唯一方法是通過密鑰輪換。
GitHub 的存儲庫架構(gòu)存在這些設(shè)計(jì)缺陷。不幸的是，絕大多數(shù) GitHub 用戶永遠(yuǎn)不會理解存儲庫網(wǎng)絡(luò)的實(shí)際工作原理，并且會因此而降低安全性。
原文鏈接：https://trufflesecurity.com/blog/anyone-can–deleted-and-private-repo-data-github
以上就是私有數(shù)據(jù)、刪掉的內(nèi)容可以永久訪問，GitHub官方：故意設(shè)計(jì)的的詳細(xì)內(nèi)容，更多請關(guān)注有卡有網(wǎng)
