安全研究人員蓄意引入漏洞？該道歉的是這些自媒體們！

就在本週，諸多中文 IT 自媒體上都出現瞭如下聳人聽聞的“原創”新聞：

乍一看，這好像是個挺大的瓜，不知情群眾紛紛點選，可是讀完這些新聞，且不從專業安全研究人員的角度來評論，單從這些新聞的標題和內容中充斥的無來源的主觀評論（例如上來就是一句“Linus Torvalds 應該要氣炸了”，實際上新聞事件和 Linus 毫無直接聯絡）和謬誤（連新聞事件主要人物盧康傑教授的名字都沒有確認的情況下就直接寫成“陸康傑”，以及“Liunx 社群”這種滑稽的拼法），就可以看出來這些報導的質量之低，以及故意提及“華人教授”所充斥著的極度自卑的心態。我們不得不指出，這些對安全研究一無所知且毫無專業素養、只關心流量的中文 IT 自媒體，在毫無根據的情況下胡亂“撰寫”所謂的“新聞”，是對專業知識的極大侮辱！事實上，這些新聞中提到的華人教授——在明尼蘇達大學任職的盧康傑教授不僅不是這些報導（以及國內各種討論社群的帖子）中想要表達的所謂“故意引入漏洞而灌水”的研究人員，反而是電腦保安研究領域的華人之光！因此，我們必須要站出來，從安全研究社群的角度對這個事件進行闡述，抨擊這些極端的言論。

首先，讓我們看看這次新聞中涉及的主要人物、領導了一系列相關安全研究的盧康傑教授是何許人也？我們很容易翻看到盧康傑教授的主頁並讀到他一系列相關研究工作。我們注意到，在新聞中提及的 2021 年 IEEE S&P 論文《On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits》發表之前，盧康傑教授研究團隊在 Linux 核心的漏洞研究方向上已經取得了諸多顯著的研究成果，包括：

• 2017 年發表在 NDSS 安全會議上的關於核心中uninitialized-use issues 的安全威脅遠比大家想象中更為嚴重的研究論文；
• 2018 IEEE S&P 論文發現了 Linux 核心中 23 個新型別的 bug——double-fetch bugs；
• 2018 年 CCS 論文中提出了針對 Linux 核心中又一類特殊 bug——lacking-recheck bugs 的檢測方法並新發現 19 個問題；
• 2019 年 Usenix Security 論文中提出對核心中 missing-check bugs 大規模高效檢測的研究，在 Linux 核心中新發現了 278 個 missing-check bug；
• 2020 年針對核心程式碼中的異常處理在不考慮上下文情況下過度保護引發錯誤的 CCS 論文；
• 2021 年 NDSS 上針對核心記憶體洩露檢測工作新發現了 218 個 bugs（其中 41 個獲得 CVE 編號）。

這一系列研究工作持續了多年，發現了海量的安全問題且均得到了頂級會議審稿人的嚴格審查，其結果的含金量不言而喻。可以這樣說，盧康傑教授可能是世界上對 Linux 核心程式碼中安全問題最瞭解的人之一！這樣一位傑出的安全研究人員，在引發爭議的研究工作產生之前已經在這個領域取得了令人矚目的成績，所領導的研究團隊已經具備了世界級的發現核心安全問題的能力，有那麼多問題可以去發掘，難道還需要故意去引入漏洞來證明自己？這讓我們想到的 2009 年的一則舊聞：

歷史總是驚人的相似，詆譭安全研究人員，製造恐慌是最好的虛假宣傳途徑。讓我們回到本次新聞事件涉及的相關研究工作上來，看看到底事情的真相是什麼。

本次事件最初是來自盧康傑教授研究組發表在今年 IEEE Security & Privacy 會議上的研究論文：

這篇論文討論了一個新型安全威脅——如果攻擊者不能直接影響開源軟體的程式碼，他們是否可以透過提交看似合理的補丁的形式來往專案中注入潛在的漏洞？這項研究其實想要回答一個很簡單的問題：當很多專案程式碼的維護者還在依賴人工程式碼審計的時候，他們到底有多少把握去排除那些存在安全威脅的程式碼提交？論文的結論是“對於 Linux 維護者來說，他們僅能排除引入的 UAF 漏洞中的 19%”。可想而知，作為開發人員，看到這個結論是不是立馬會暴怒：“你找到這麼多我們的 bug，我們早就受夠了，你還要製造 bug 來誘使我上當” ？！可是事實上，這正暴露了開發人員在對待安全風險時的基本思維缺陷：試想一下，難道攻擊者一定會按照開發人員的假設來出牌嗎？開發人員總是假定自己面對的都是善意的交流，而安全研究人員卻站在攻擊者的角度來想問題。換句話說，安全研究人員是透過一種“模擬罪犯的思維和行為”的模式來預防犯罪啊！面對溫和的安全壓力測試反而慍怒，程式碼 bug 和漏洞卻一直層出不窮，為什麼 Linux 核心社群就不能透過此次事件反省一下，在程式碼稽核的過程中不光針對程式碼功能，也應該引入更多的安全研究專家和程式碼安全分析技術來保護開發流程和修補流程呢？

再舉個例子，同學們，你們可以去搜尋一下下面這篇論文：

如果不是這篇由 MIT 的三名學生用機器生成的論文去進行的“學術釣魚測試”並被某個學術會議的審稿人一致透過，我們恐怕都不知道，很多學術會議的審稿質量究竟有多低。而你完全可以用同樣的邏輯說“審稿人都是義務勞動，憑什麼你要用機器生成的論文去浪費審稿人的時間”？既然站在審稿人這個位置上，就要考慮到各種可能出現的情況，並負責任地去解決所有會遇到的問題。類似地，如果你不考慮惡意提交的可能性，在過去、現在和未來的任何一個時刻都可能會有真正的惡意攻擊者去精心提交有問題的補丁來構造攻擊。事實上，這樣的例子上真實存在，且背後的主謀是大名鼎鼎的 NSA：它往 NIST 2007 年釋出的確定性隨機數產生器推薦標準 SP800-90 修訂版中引入了一個有問題的隨機數發生器 Dual_EC_DRBG，若不是在 4 個月後 Crypto 2007 會議上由安全研究人員 Dan Shumow 和 Niels Ferguson 發表的報告中指出其中的問題，恐怕現在 NSA 監控的手腳又伸得更長了吧？！

其次，在諸多新聞報導甚至很多專業人士的評論中，我們發現了海量的謬誤說法甚至是誤導，讓大家以為盧康傑教授研究團隊在“蓄意引入漏洞”，而實際情況根本不是這樣！比如下面這個評論

這個貼子看上去很合理，實際上和貼大字報並沒有什麼區別，因為“往 Linux Kernel 裡面提交了 200 多個有 bug 的假程式碼”完全是道聽途說的傳謠信謠。盧康傑教授證實過，首先，他們在 S&P 論文的研究過程中根本沒有提交過任何真正有漏洞的程式碼，只有 3 個實驗性的有問題的 PoC 補丁，不會引入實質性威脅，且當這些測試被核心社群確認之後，他們就立即中止修補流程並通知相關稽核者，保證了安全性不會遭到破壞，也沒有給核心維護人員增加太多的負擔（如果你連 3 個潛在有問題的程式碼稽核都覺得費時間，那麼是不是該假定任何提交都不會有問題而乾脆取消程式碼稽核呢？）；其次，所謂“200 多個假程式碼”其實包括了盧教授研究團隊此前提交過的大量有效補丁（我們前面在介紹盧教授研究工作時也提到過），涉及核心中由開發者引入、真實存在的安全問題，對核心安全增強有極大幫助，可核心社群的維護者們以 2021 年 4 月盧教授團隊的一些新提交補丁存在問題為名，乾脆實施了連坐政策（沒錯，現在是 2021 年，人類文明已經進入到了資訊時代），一股腦將此前提交的這些補丁都撤銷了，我們可以想象一下，在長期被研究人員發現問題之後，終於等到一次對方提交的問題不是那麼高質量，於是藉機就把對方此前所有的工作全部否定，這可是真正的“惱羞成怒”吧？

事實上，過去的 20 年裡安全研究會議上發表了大量安全攻擊的相關論文，找到了各類系統中不計其數的安全問題，而這些研究不僅沒有毀滅這個世界，反而極大推動了計算機系統安全的進步。反過來，我們可以看另一個極端的例子，在 2013 年 Usenix Security 會議上，研究人員發表了一篇論文，介紹了他們突破奧迪、保時捷、賓利和蘭博基尼等大眾汽車集團旗下豪華車品牌的 Megamos Crypto 防護系統的研究工作，然而大眾集團竟然訴諸英國高等法院，請求釋出暫時性禁令，阻止三名專家發表論文。然而後面發生的事情我們也都知道，2015 年 9 月大眾“排放門”醜聞爆發，該集團在全球範圍內為 1100 萬輛汽車安裝了“減效裝置”，使車輛在監管測試中比在實際駕駛環境中看起來汙染更少。這和他們對待安全問題的態度倒是保持得非常一致啊（值得一提的是，2013 年的研究論文終於在 2015 年 8 月的 Usenix Security 會議上得到解禁！）

我們發現，還有一些意見甚至認為盧康傑教授應該為這些研究工作表達“愧疚”，恐怕是對安全研究人員日常工作的無知。大家都知道國內外各大 IT 公司都有專門的安全應急響應中心，並且對安全研究人員提交漏洞這件事提供了賞金，對安全研究人員幫助他們的產品提高安全性表示感謝，而不是動輒站在道德制高點上譴責對方。實際上，如果不是安全研究人員而是真正的攻擊者發現了這些漏洞並展開攻擊，你覺得後果會只是在郵件裡面吵吵架這麼簡單嗎？如果大家對安全研究人員在工作中所保持的這種攻擊者思維模式感到不解，強烈建議大家去閱讀著名的安全專家 Niels Ferguson 和 Bruce Schneier 等所寫的《Cryptography Engineering》這本書，其中第一章就很好地介紹了作為安全專家應該怎麼樣去思考問題：

從另一個側面來說，開發人員對安全問題的漠視，其實也是安全研究人員逼不得已，不得不透過進行一些模擬安全攻擊來證實自己的分析確實有效的原因。為了逼迫開發人員重視安全，一個真正“過分”的安全研究團隊——Google Project Zero 安全團隊，在保護使用者方面，可以說是發起狠來連自己人都打，他們不僅經常公開微軟的安全漏洞倒逼微軟儘快修復問題，甚至連自家政府的駭客行動也被他們曝光。做出了這樣的安全研究工作，美國政府是不是要把研究人員都投到監獄裡去呢？

最後，我們想說，那些自媒體新聞還真的挺有影響力的，例如前面提到他們杜撰的“Linus Torvalds 應該要氣炸了”，Linus 本人可能是在閱讀了國內諸多自媒體之後才知道自己氣炸了，於是出來稽核了盧康傑教授研究組被撤回的 200 多個補丁，並發現裡面大部分都是有效的，沒有任何惡意漏洞，親自發表了評論。看來對於撤回補丁這件事，他是最終真的“氣炸了”

---

文中圖片素材均來自網路，題圖來自 pixabay。

參考文獻：

• [1] Lu, K., Walter, M. T., Pfaff, D., Nümberger, S., Lee, W., & Backes, M. (2017, February). Unleashing Use-Before-Initialization Vulnerabilities in the Linux Kernel Using Targeted Stack Spraying. In NDSS.
• [2] Xu, M., Qian, C., Lu, K., Backes, M., & Kim, T. (2018, May). Precise and scalable detection of double-fetch bugs in OS kernels. In 2018 IEEE Symposium on Security and Privacy (SP) (pp. 661-678). IEEE.
• [3] Wang, W., Lu, K., & Yew, P. C. (2018, October). Check it again: Detecting lacking-recheck bugs in os kernels. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (pp. 1899-1913).
• [4] Lu, K., Pakki, A., & Wu, Q. (2019). Detecting missing-check bugs via semantic-and context-aware criticalness and constraints inferences. In 28th {USENIX} Security Symposium ({USENIX} Security 19) (pp. 1769-1786).
• [5] Pakki, A., & Lu, K. (2020, October). Exaggerated Error Handling Hurts! An In-Depth Study and Context-Aware Detection. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (pp. 1203-1218).
• [6] Emamdoost, N., Wu, Q., Lu, K., & McCamant, S. Detecting Kernel Memory Leaks in Specialized Modules with Ownership Reasoning.
• [7] Stribling, J., Aguayo, D., & Krohn, M. (2005). Rooter: A methodology for the typical unification of access points and redundancy. Journal of Irreproducible Results, 49(3), 5.
• [8] Verdult, R., Garcia, F. D., & Ege, B. (2015). Dismantling megamos crypto: Wirelessly lockpicking a vehicle immobilizer. In Supplement to the Proceedings of 22nd {USENIX} Security Symposium (Supplement to {USENIX} Security 15) (pp. 703-718).
• [9] Ferguson, N., Schneier, B., & Kohno, T. (2010). Cryptography engineering. Design Princi.

---

本文轉載自微信公眾號“安全研究GoSSIP”，如需轉載請進入公眾號聯絡相關人員