信息來源:51CTO
漏洞與攻擊無處不在。最近,劍橋大學的兩位研究人員發(fā)現(xiàn)了一個可以影響計算機代碼編譯器和軟件開發(fā)環(huán)境的漏洞——Trojan Source(木馬源) 。該漏洞幾乎影響所有計算機語言,包括對 C、C++、C#、JavaScript、Java、Rust、Go 和 Python 。
此外,惡意代碼可以將 Trojan Source 用于供應鏈攻擊。
-
論文地址:https://trojansource.codes/trojan-source.pdf
-
GitHub 地址:https://github.com/nickboucher/trojan-source
Trojan Source 攻擊方法利用的是字符編碼標準 Unicode ,有以下兩種攻擊方式:
-
第一種是通過 Unicode 的 Bidi 算法(CVE-2021-42574),該算法處理從左到右(如英語)和從右到左(如阿拉伯語和希伯來語)腳本顯示順序。該漏洞允許對字符進行視覺上的重新排序,使其呈現(xiàn)與編譯器和解釋器所不同的邏輯順序;
-
第二種是同源攻擊 (CVE-2021-42694),兩個不同的字符具有相似的視覺表示,例如拉丁語 H 和西里爾字母Н。
研究人員表示如果攻擊者通過逃過人類審閱成功地將目標漏洞提交到開源代碼中,下游軟件可能會繼承該漏洞。在 GitHub 上的存儲庫中,他們提供了概念驗證 (PoC) 腳本。
Trojan-Source 攻擊
字符重新排序方式
Unicode 標準規(guī)定,內存表示順序稱為邏輯順序,當文本在一行的時候,大多數(shù)腳本從左往右顯示字符(例如英語)。然而,也有一些腳本(如阿拉伯語或希伯來語)顯示文本的自然順序是從右往左。當混合具有不同顯示順序的腳本時,必須有一種確定性的方法來解決方向沖突。對于 Unicode 來說,雙向或 Bidi 算法可以實現(xiàn)。
某些場景下,Bidi 算法設置的默認排序可能不夠。對于這些情況,Bidi 算法提供覆蓋控制字符(override control characters)。Bidi 算法覆蓋是不可見的字符,從而可以切換字符組的顯示順序。
例如,考慮以下 Unicode 字符序列:RLI a b c PDI,那么將顯示為:c b a。
下表 I 提供了與此攻擊相關的控制符列表:
隔離重新排序方式
在 Bidi 規(guī)范中,隔離(isolates)是被視為單個實體的字符組;也就是說,當顯示順序被重寫時,整個一組字符將作為單個塊移動,隔離可以嵌套。
假設 Unicode 字符為:RLI LRI 4 5 6 PDI LRI 1 2 3 PDI PDI,那么將顯示為:1 2 3 4 5 6。
相互嵌入多層 LRI 和 RLI,可以近乎任意地重新排序字符串。那么攻擊者就可以將雜亂的字符,經(jīng)過這種方式,將自己想要的功能插入到當前的開源項目中,讓用戶下載后執(zhí)行,從而在不知情的情況下來執(zhí)行漏洞代碼。
語法依從性
大多數(shù)設計良好的編程語言不允許在源代碼中使用任意控制字符,因為它們被視為影響邏輯的 token。因此,在源代碼中隨機放置 Bidi 覆蓋字符通常會導致編譯器或解釋器語法錯誤。為了避免這種錯誤,我們可以利用編程語言的以下兩個原則:
-
注釋:大多數(shù)編程語言都允許編譯器和解釋器忽略所有文本(包括控制符)注釋;
-
字符串:許多編程語言允許字符串可以包含任意字符,同理也包括控制符。
雖然注釋和字符串都具有指示其開始和結束的特定于語法的語義,但 Bidi 覆蓋不遵守這些界限。因此,通過將 Bidi 覆蓋字符專門放置在注釋和字符串中,我們能夠以大多數(shù)編譯器可接受的方式將它們注入到源代碼中。
示例展示
如下圖所示,通過任意控制符改變了代碼邏輯。下列代碼中的 if 條件沒有執(zhí)行,而是被放置在注釋部分,程序顯示效果起到了欺騙用戶的作用。
研究人員還展示了如何在 C++ 中執(zhí)行同源文字攻擊。他們使用了兩個看起來相似但實際上不同的 H,藍色的拉丁語 H 和紅色的西里爾字母Н。當進行編譯時,該程序輸出文本「Goodbye, World!」。
加強防御
這樣的攻擊可能很難檢測,因為經(jīng)過渲染的源代碼看起來非常完美。如果邏輯上的變化足夠微小,以至于后續(xù)測試中未被發(fā)現(xiàn),那么攻擊者可能會在不被發(fā)現(xiàn)的情況下引入有針對性的漏洞。
同樣令人擔憂的是,Bidi 覆蓋字符通過復制、粘貼操作,仍然存在于瀏覽器、編輯器和操作系統(tǒng)上。
「開發(fā)者將代碼從不受信任的來源復制到受保護的代碼庫中,這種做法可能無意中引入了一個不可見漏洞,」劍橋大學計算機安全教授、該研究的合著者 Anderson 表示。「這種代碼復制是現(xiàn)實世界安全漏洞的重要來源。」
約翰霍普金斯信息安全研究所的副教授 Matthew Green 表示,「劍橋研究清楚地表明,大多數(shù)編譯器都可以被 Unicode 欺騙,以不同于研究者預期的方式處理代碼?!?
好消息是,研究人員進行了廣泛的漏洞掃描,還沒有人利用這一漏洞。壞消息是目前還沒有防御措施,將來可能會有人利用該漏洞進行一些破壞。
Green 表示:希望編譯器和代碼編輯器開發(fā)人員能夠快速修補這個漏洞!但由于有些人不定期更新他們的開發(fā)工具,至少在一段時間內會有一些風險。
圖源:XKCD.com/2347/
加州大學伯克利分校計算機科學系的講師 Nicholas Weaver 表示,劍橋提出了一組非常簡單、優(yōu)雅的攻擊,可能會使供應鏈攻擊變得更加嚴重。
人類已經(jīng)很難從源代碼中區(qū)分「this is OK、this is evil」,Weaver 表示。對于這種攻擊,你可以使用改變方向來改變注釋和字符串的呈現(xiàn)方式,例如「This is okay」只是一種呈現(xiàn)形式,但「This is」okay 才是它在代碼中的存在方式。幸運的是,它有一個非常容易掃描的標記,因此編譯器在將來遇到它時可以「檢測」它。
研究人員表示,軟件公司在最初披露期間,提供了 99 天的禁錮期,以允許通過軟件更新修復受影響的產(chǎn)品。
研究人員寫道:「我們收到了各種各樣的回應,包括修補承諾、Bug 賞金計劃、快速駁回等。在我們與之合作的 19 家軟件供應商中,有 7 家使用外包平臺接收漏洞披露,6 家擁有專門的漏洞披露門戶網(wǎng)站,4 家通過 PGP 加密電子郵件接受披露,另外兩家僅通過非 PGP 電子郵件接受披露。他們都確認收到了我們的披露,最終 9 家承諾發(fā)布補丁?!?
此外,還有 11 家接受者有 Bug 賞金計劃,為漏洞披露提供報酬。但研究人員報告說,只有 5 家支付賞金,平均支付 2,246 美元。
Anderson 表示,「到目前為止大約有一半的組織已經(jīng)承諾提供補丁,而其他組織還在拖延。我們將接下來將監(jiān)控他們的部署,還希望 GitHub、Gitlab 、 Atlassian 采取行動?!?
參考鏈接:
https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/http://cn-sec.com/archives/609155.htmlhttp://cn-sec.com/archives/609155.html