LWN: Git中的一個(gè)漏洞！
關(guān)注了就能看到更多這么棒的文章哦～
A vulnerability in Git
By Jake Edge
March 10, 2021
DeepL assisted translation
https://lwn.net/Articles/848935/
3 月 9 日，Git（知名的分布式版本控制系統(tǒng)）中公開(kāi)了一個(gè)嚴(yán)重的潛在漏洞。漏洞的詳細(xì)描述中有很多限定詞，因此看起來(lái)它的適用條件非常嚴(yán)苛，事實(shí)也確實(shí)是這樣。因此它并不是那么令人擔(dān)憂，但這并不絕對(duì)。與大多數(shù)漏洞一樣，它是否會(huì)被利用取決于軟件的使用方式和運(yùn)行環(huán)境。
在對(duì)一個(gè)精心制作來(lái)利用該漏洞(CVE-2021-213)的倉(cāng)庫(kù)進(jìn)行 clone 時(shí)，可能會(huì)在本地系統(tǒng)上發(fā)生非法代碼執(zhí)行（code execution on the local system）。前提條件之一是要安裝了某種 Git filter。Filters 允許本地文件系統(tǒng)中的 Git 倉(cāng)庫(kù)和遠(yuǎn)程倉(cāng)庫(kù)中過(guò)濾掉一部分文件；"smudge" filter 用在從 repository 中提取 blobs（二進(jìn)制對(duì)象）并存儲(chǔ)到當(dāng)前工作目錄中的過(guò)程中，而 "clean" filter 則可以在將文件提交到 repository 時(shí)對(duì)其進(jìn)行修改。需要使用哪種類型的 filter，取決于打算進(jìn)行什么類型的轉(zhuǎn)換。Git 大文件存儲(chǔ)（LFS）是一個(gè)很常用的擴(kuò)展（其中使用了 smudge 和 clean filter），Windows 版本的 Git 默認(rèn)就安裝了 LFS。
使用 filter 時(shí)可以將一些 Git 操作的處理延后，這樣一來(lái)那些需要長(zhǎng)期運(yùn)行的 filter 動(dòng)作可以在后臺(tái)進(jìn)行。例如，Git LFS 可能需要在通過(guò)網(wǎng)絡(luò)來(lái)復(fù)制一個(gè)大文件從而完成 git checkout 操作。不過(guò)，這個(gè)延后的動(dòng)作就改變了 Git 正常處理文件和目錄的順序。這就意味著緩存的信息在被用到時(shí)可能已經(jīng)失效了，這正是漏洞出現(xiàn)的原因。
為了減少調(diào)用 lstat()的次數(shù)，Git 維護(hù)了一個(gè) "lstat cache"。如果在文件被 checkout 的過(guò)程中發(fā)生了路徑?jīng)_突（path collision，即兩個(gè)文件的路徑和文件名都相同），例如兩個(gè)名稱中僅有大小寫不同的文件被 checkout 到一個(gè)不區(qū)分大小寫的文件系統(tǒng)中，那么這個(gè) cache 就可能是錯(cuò)誤的。這通常不會(huì)導(dǎo)致問(wèn)題，因?yàn)?checkout 是按照順序進(jìn)行的，所以就算碰上緩存錯(cuò)誤了，但是此時(shí) cache 實(shí)際上也用不上。
然而，如果 checkout 中某些動(dòng)作被 filter 延后了，那么就會(huì)有風(fēng)險(xiǎn)了。在查詢 cache 時(shí)，cache 中的文件的類型可能發(fā)生了變化，如果這種變化是由攻擊者精心構(gòu)造的，那么就會(huì)出現(xiàn)惡意攻擊行為了。修復(fù)該漏洞的 patch中是這樣描述的：
但是， checkout 機(jī)制中有一些情況并不總是遵循 index 順序的。具體來(lái)說(shuō)：checkout-index 會(huì)按照命令行上（或 stdin）上出現(xiàn)的順序來(lái)寫入 path 信息，而 delayed checkout 功能（用在某個(gè)需要長(zhǎng)時(shí)間運(yùn)行的 filter 進(jìn)程回復(fù) "status=delayed"）則會(huì)推遲一些內(nèi)容的 checkout 操作，從而導(dǎo)致 checkout 順序變化了。
當(dāng)我們必須不按順序 checkout 某個(gè)文件時(shí)并且 lstat() cache 此時(shí)是 invalid 的（由于之前提到的路徑碰撞），那么 checkout_entry() 可能最終用到的就是這個(gè) invalid 的數(shù)據(jù)，并[相信] 這個(gè)文件名之前的那串路徑都是真實(shí)的目錄，從而被欺騙了。比如目錄部分實(shí)際上是一個(gè)普通文件，那么用戶會(huì)得到一個(gè)錯(cuò)誤。"fatal: unable to create file 'foo/bar'. Not a directory"。但如果目錄部分被換了一個(gè)符號(hào)鏈接[symbolic link]，那么 checkout 動(dòng)作實(shí)際上可能最終會(huì)跟隨符號(hào)鏈接將文件寫在一個(gè)錯(cuò)誤的地方，甚至是在 git repository 之外的位置。delayed checkout 就會(huì)受這個(gè)影響，它可能會(huì)被攻擊者用來(lái)制作出有問(wèn)題的 repository，等人們 clone 時(shí)進(jìn)行寫破壞。
修復(fù)時(shí)人們考慮了幾種方案，比如在進(jìn)行不按順序的 checkout 操作時(shí)禁用 cache，或者對(duì)文件名進(jìn)行排序，使其始終是按相同的順序處理的。這兩種方法都會(huì)影響性能，而且人們擔(dān)心其他還會(huì)有一些情況下也會(huì)導(dǎo)致出現(xiàn)類似 delayed checkout 這樣的亂序操作，從而使這個(gè) bug 死灰復(fù)燃。因此最終選擇的解決方案是，每次執(zhí)行刪除目錄操作時(shí)，就會(huì)對(duì) cache 進(jìn)行 invalidate 操作。
如上所述，符號(hào)鏈接在這個(gè)過(guò)程中起到了幫兇的作用。雖然符號(hào)鏈接非常有用，但歷史上它也曾被各種利用來(lái)進(jìn)行破壞。在 race condition exploits（例如臨時(shí)文件）中就經(jīng)常利用符號(hào)鏈接。并非所有的系統(tǒng)都支持符號(hào)鏈接，但是 Unix 衍生系統(tǒng)（Linux、macOS）一般都支持。如今，Windows 管理員也可以創(chuàng)建符號(hào)鏈接了。
因此，這幾個(gè)不同的功能和特殊情況組合在一起，就導(dǎo)致了一個(gè)系統(tǒng)漏洞，此外還需要有一個(gè)攻擊者精心制作的 Git repository，并且用戶被欺騙去對(duì)其進(jìn)行 clone 操作。哪怕是對(duì) Windows 系統(tǒng)這種既使用 Git LFS 而且文件系統(tǒng)也不區(qū)分大小寫的系統(tǒng)，利用這個(gè)漏洞的攻擊也并沒(méi)有怎么見(jiàn)到過(guò)，也許可能根本不存在。這看起來(lái)是通過(guò)代碼審查或測(cè)試發(fā)現(xiàn)的問(wèn)題，隨后被報(bào)告出來(lái)并并迅速修復(fù)了，甚至都來(lái)不及起一個(gè)好聽(tīng)的名字、設(shè)計(jì)個(gè) logo、或者建個(gè)專門的網(wǎng)站。如果真有系統(tǒng)被利用這個(gè)漏洞攻破了，那么很可能是因?yàn)檫@些攻擊非常具有針對(duì)性，并且還沒(méi)有被發(fā)現(xiàn)。
雖然 Linux 原生文件系統(tǒng)通常都會(huì)區(qū)分大小寫，但事實(shí)上可以被配置為忽略大小寫。不僅如此，Linux 還可能在使用 Windows 和 macOS 的那些忽略大小寫的文件系統(tǒng)格式。此外，fix patch 中提供的測(cè)試程序還揭示了另一種會(huì)導(dǎo)致問(wèn)題的方式，那就是利用 Unicode normalization。測(cè)試程序使用了 "?" 的兩種不同的 Unicode 表示形式（U+0061 U+0308，"\141\314\210"，和 U+00e4，"\303\244"），并確保文件不會(huì)被寫到錯(cuò)誤的位置。因此，Linux 系統(tǒng)雖然受該 bug 影響的可能性很小，但也并不可以高枕無(wú)憂的。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長(zhǎng)按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開(kāi)源社區(qū)的各種新近言論～