技術編輯：典典丨發自 思否編輯部

11 月 1 日，劍橋大學研究人員發現了一個可影響當今大多數計算機軟體程式碼編譯器和軟體開發環境的漏洞。這個漏洞來自數字文字編碼標準 Unicode 的一個元件，與 Unicode 雙向演算法“bidi”相關。

危及幾乎所有軟體的超級漏洞

Unicode 目前在 154 中不同的程式語言指令碼中定義了超過 14。3 萬個字元（除了一些非指令碼字符集，例如表情符號）。

該漏洞被命名為“原木馬”（Trojan Source），該演算法處理包含具有不同顯示順序的混合指令碼的顯示文字，例如阿拉伯語（從右到左閱讀）和英語（從左到右）。

大多數程式語言都允許開發者將 bidi 字元放在字串文字和註釋裡邊，

但是，註釋和字串需要遵守語法，Bidi overrides 卻不用遵守。

因此，將一段程式碼使用 Bidi 演算法多層 LRI 和 RLI 相互嵌入，就可以把其中的字串任意組合，重新排序。如果你有足夠的時間，甚至可以重排一份原始碼的字元，生成一份新的符合語法規範的程式碼。

這是第一個危及幾乎所有軟體的，“簡潔優雅的”超級漏洞。

對所有支援 Unicode 的語言不利

劍橋大學計算機安全教授、該研究的合著者羅斯·安德森稱：

“對於像 Linux 和 Webkit 這樣的專案來說，這絕對是個壞訊息，這些專案接受任何人的程式碼貢獻，人工稽核後將它們合併到關鍵程式碼中。據我所知，這個漏洞是第一個影響幾乎所有（軟體）的漏洞。”

如果這個漏洞被用於惡意攻擊，將導致一個很大的問題：審查者看到的程式碼邏輯很可能和編譯器編譯出來的程式邏輯不一樣。

來看一下這個 python 的例子：

圖一和圖二都定義 alice 的值為100， 並呼叫同一個函式：將 alice 減去 50 ，根據程式邏輯，兩組程式都應該返回 50。

但圖一插入了 RLI ，subtract_funds 函式體的 return 實際上是由於 bidi RLI 覆蓋而執行的，因此圖一的 bank _=amount 語句永遠也不會執行，只會返回 100 。

相同的原理也可以應用於其他語言，

這個漏洞實際上是 Unicode 自身的問題，卻實實在在地影響到了所有支援 Unicode 的語言

，包括 C、C++、C#、JavaScript、Java、Rust、Go 和 Python 等一系列流行的程式語言。

安德森表示，這樣的攻擊對於人類程式碼審查人員來說可能很難檢測到，因為渲染的原始碼看起來完全可以接受。

“如果邏輯上的變化足夠微妙，以至於在後續測試中未被發現，那麼攻擊者可能會在不被發現的情況下引入有針對性的漏洞”，他說。

大多數編譯器都可以被 Unicode 欺騙

同樣令人擔憂的是，Bidi 控制字元透過大多數現代瀏覽器、編輯器和作業系統上的複製和貼上功能駐留。

“任何將程式碼從不受信任的來源複製到受保護的程式碼庫中的開發人員都可能無意中引入了一個不可見的漏洞。”安德森指出：“這種程式碼複製是現實世界安全漏洞的重要來源。”

約翰霍普金斯資訊保安研究所副教授馬修格林表示，劍橋的研究清楚地表明，

大多數編譯器都可以被 Unicode 欺騙，以不同於讀者預期的方式處理程式碼。

格林說，

好訊息是研究人員進行了廣泛的漏洞掃描，但無法找到任何人正在利用此漏洞的證據。

但是：

“

壞訊息是它沒有防禦措施，現在人們知道了，不法分子可能會開始利用它。

”

“希望編譯器和程式碼編輯器開發人員能夠快速修補這個問題！但由於有些人不定期更新開發工具，至少在一段時間內會有一些風險。”

安德森指出，到目前為止，

大約一半負責維護受影響的計算機程式語言的組織已經承諾提供補丁，但其他人正在拖延。

“我們將在接下來的幾天內監控他們的部署，”安德森說。“我們還期待 Github、Gitlab 和 Atlassian 採取行動，因此他們的工具應該能夠檢測對仍然缺乏雙向字元過濾的語言的程式碼的攻擊。”

至於需要對 Trojan Source 採取什麼措施，研究人員敦促依賴關鍵軟體的政府和公司確定其供應商的安全態勢，向他們施加壓力以部署足夠的防禦，並確保工具鏈中任何一個環節都被覆蓋。

截至目前，Rust  已針對此安全漏洞釋出了安全公告，漏洞編號為 CVE-2021-42574 和 CVE-2021-42694。

- END -