劍橋大學的專家日前發出了一份報告，指出一個安全漏洞將影響大部份現代的編譯器，透過新攻擊方式，使用開發工具的合法功能，在源代碼中顯示的內容與編譯的內容原全不同，其原理是通過Unicode控制字元(control characters)。
在大部份時間這些字元都不會和其他編碼一樣出現(雖然有部份編輯器會顯示他們)，但他們以某種方法修改了文字，例如這裡所包含了Unicode Bidirectional (Bidi)演算法。可能大家都知道，部份人類語言書寫由左至右(例如英語)，也有部份由右至左(例如阿拉伯語)，當編碼只含有一種語言時並沒有問題，但當需要時，例如一行同時包含英語和阿拉伯語，Bidi編碼指定文字方向。
使用這種編碼的製作者，例如在Python編碼把comment terminator從中一行的中間移到末端，他們應用RLI編碼去轉換幾個字符，其他並不受到影響。程式員在檢查編碼時會看見右邊的版本，但左邊的顯示才是編碼的真正執行方法。大部份編譯器無視控制字元，所有人檢查編碼都會以為第五行屬於無害，而事實是，隱藏在內的提前還款語句，會導致程式跳過借記銀行帳戶資金的操作。即是在這個例子中，模擬的銀行程式將會付出金錢但不會減少帳戶結餘。
危險的原因
乍看下這個漏洞看起來太簡單，誰會加入隱藏的字元，希望騙過源代碼的審計師，然而這個問題足以成為漏洞識別之一(CVE-2021-42574)，在發表論文之前作者已知會大部份常見編譯器的開發人員，給序他們時間進行補丁。
報告指出基本攻擊的可行性，兩種執行策略用來隱藏comment內的指令，以及隱藏展示於螢幕。
真實的危險性
在論文發佈後的短時間後，程式員Russ Cox反駁Trojan Source攻擊，他婉轉地表示對其不贊賞，而他的論點包括：
- 這完全不是新攻擊
- 很多編碼編輯器使用語法突出顯示「隱形」編碼
- 無需對編譯器補丁，小心檢查編碼去偵測任何意外或惡意臭蟲便足夠
事實上，Unicode控制字元的問題早在2017年已經浮現，Homoglyphs也有相似的問題，字元看起來相同但擁有不同編碼，絕非新事物以及可以用來使無關代碼瞞騙手動檢查。然而，Cox的重點分析並沒有否定問題的存在，而是譴責報導過於戲劇化。
Trojan Source的問題千真萬確，只是很幸運地解決方法相對簡單，所有補丁以經準備或已經推出去阻止編碼含有類似的字元(查看Rust編譯器開發人員的通知)，如果大家使用自己的軟件去製作工具，我們建議加入相似的隱藏字元檢查。
供應鏈攻擊的危險
很多公司把他們的項目外判開發工作給承包商，或使用現成的開源模組，這經常對供應鏈攻擊大開中門，網絡犯罪份子可以入侵承包商或在開源項內中嵌入代碼，使軟件的最終版本加入了惡意編碼。編碼審查員很可能會把後門發現，但一旦他們沒有發現，用戶即使從可信的來源取得軟件，但仍然使他們失去資料。
Trojan Source是一種比較「優雅」的攻擊示範，攻擊者無需嘗試把大量字節的惡意代碼放入最終產品內，而是使用這種方法，將難以被偵測的內容植入軟件的重要部份，然後在未來數年內加以利用。
維持安全的方法
防範Trojan Source類型的攻擊：
- 更新使用的所有程式語言編譯器(如果已有補丁推出的話)
- 自行編寫腳本去偵測在源代碼內的控制字元
資料來源：Kaspersky Blog
