如同微軟想盡辦法讓消費者盡可能地更新到最新的 Windows 11 系統一樣，美國安全機構無時無刻也不在發力，希望廣大程式員可以使用 Rust 等更安全的語言替代掉無法自動防止記憶體錯誤的語言如 C、C++ 等。
Image Creator from Microsoft Designer
美國安全機構再發 22 頁報告，“劍指”開源軟體
近日，美國網絡安全部門（CISA）聯合美國聯邦調查局（FBI）、澳洲信号局（ASD）、澳洲網絡安全中心（ACSC）和加拿大網絡安全中心（CCCS）共五大機構又釋出了一份 22 頁的調查報告——《探索關鍵開源項目中的記憶體安全》，總結了他們對 OSS 中使用記憶體不安全代碼的調查結果。
以 GitHub 代碼托管平台和 OpenSSF（開源安全基金會）為調研平台，CISA 這些機構此番分析了全球 172 個關鍵開源項目，包含了 Chromium、Linux、MySQL Server、TensorFlow、JDK、Node、KVM、GCC 等主流的浏覽器、作業系統、資料庫、架構項目。
同時，CISA 等機構使用的記憶體不安全語言定義如下，覆寫 Assembly、C、C++、Cython 等記憶體不安全程式設計語言。
根據調查，其得出以下一些結論：
- 172 個項目中有 52% 是使用 C、C++ 和其他所謂“記憶體不安全”的語言編寫的。
- 所有項目的總代碼行（LoC）中有 55% 是用記憶體不安全的語言編寫的。
- 最主流的一些項目在很大程度上是用記憶體不安全的程式設計語言編寫的。在按 LoC 總數計算的十大項目中，每個項目使用記憶體不安全 LoC 的比例都超過了 26%。在這十個項目中，使用記憶體不安全語言的比例中位數為 62.5%，十個項目中有四個項目的比例超過 94%。
- 對用記憶體安全語言編寫的三個項目進行的依賴性分析表明，每個項目都依賴于用記憶體不安全語言編寫的其他元件。
具體來看，根據調研資料顯示，總共有 26023 KLoC（千行代碼）的 Linux 項目中，約 95% 的代碼行都是記憶體不安全的；對于 MySQL Server，這一比例為 84%；對于 TensorFlow，這個數字是 64%；對于 Zephyr，這個數字是 84%；對于 Chromium，這個數字是 51%。
平均而言，10 個最大的開源項目中，總代碼行中有 26% 是記憶體不安全的代碼。即使是用記憶體安全語言編寫的項目也因依賴不安全的元件而面臨風險。
與此同時，報告稱，「我們确定所分析的大多數關鍵開源項目，甚至那些用記憶體安全語言編寫的項目，都可能包含記憶體安全漏洞。這可能是由于直接使用記憶體不安全的語言或外部依賴使用記憶體不安全性的語言的項目造成的。此外，禁用記憶體安全的低級功能需求可能會在以其他記憶體安全語言編寫的代碼中造成記憶體安全漏洞。這些限制凸顯了繼續認真使用記憶體安全程式設計語言、安全編碼實踐和安全測試的必要性。」
多份報告相繼釋出：呼籲棄用 C/C++ 等記憶體不安全的程式設計語言
事實上，近幾年來，業界愈發關注記憶體安全問題。據安全組織 Security Planner 于 2022 年 10 月釋出的一份《消費者報告》(https://advocacy.consumerreports.org/wp-content/uploads/2023/01/Memory-Safety-Convening-Report.pdf)指出，“大約 60%-70% 的浏覽器和核心漏洞——以及在 C/C++ 代碼庫中發現的安全漏洞——是由于記憶體不安全導緻的。”該報告還引用了一段關于使用記憶體安全語言代替記憶體不安全語言的安全成本和收益的有趣讨論。
自此，使用更加安全的記憶體語言便成為美國多個政府機構引導的主要方向，這也是其連發多個檔案、呼籲項目遷移到更安全程式設計語言的原因：
- 2022 年 11 月，美國國家安全局（NSA）釋出了關于保護軟體開發者和營運商免受記憶體安全問題影響的指南，鼓勵多個組織将程式設計語言從 C/C++ 轉為使用記憶體安全的語言，如 C#、Rust、Go、Java、Ruby 和 Swift，主要原因是這樣可以幫助軟體開發者和使用者預防并緩解軟體記憶體安全問題，這些問題占可利用漏洞的很大一部分；
- 2023 年 3 月釋出的《2023年國家網絡安全戰略》和2023年7月釋出的相應實施計劃均讨論了投資于記憶體安全并與開源社群合作的内容。《國家網絡安全戰略實施計劃》的第4.1.2項倡議“促進開源軟體安全和記憶體安全程式設計語言的采用”訓示建立“開源軟體安全倡議（OS3I）以推動記憶體安全程式設計語言和開源軟體安全的采用。” 同一檔案中的第4.2.1項倡議“加速記憶體安全程式設計語言的成熟、采用和安全性”也呼籲投資于記憶體安全程式設計語言，并尋求新成立的OS3I的參與。
- 2023 年 12 月，美國網絡安全和基礎設施局 (CISA)也開始聯合 NSA、美國聯邦調查局 (FBI) 以及澳洲、加拿大、英國和紐西蘭的網絡安全機構釋出了一份 23 頁的《記憶體安全路線圖指南》，這份檔案指出，記憶體安全漏洞是最常見的軟體漏洞類型之一，并給軟體制造商和消費者帶來修複、及時響應和其他努力相關的巨大成本。建議軟體制造商建立記憶體安全路線圖，包括解決外部依賴（通常包括開放源代碼軟體）中的記憶體安全的計劃。
- 2024 年 2 月，美國白宮國家網絡主任辦公室 (ONCD)在一份主題為《回到基礎構件：通往安全軟體之路》的 19 頁 PDF 報告中強烈呼籲道，“C、C++ 不安全，新應用開發時就别用了，舊應用應該采取遷移行動”。
時下，CISA 聯合其他國際安全組織釋出的報告直接揭曉了一些主流開源項目中使用的不安全記憶體語言編寫的代碼行數，其也遵循了以上戰略路線，希望引發開發者、企業的注意，有效避免記憶體安全錯誤。
各大科技公司已經開始“重寫”、“遷移”等行動
這份報告也再次強調，像 C 和 C++ 這樣的記憶體不安全程式設計語言允許程式員對代碼中的記憶體相關功能進行更直接的控制，這通常會導緻非常常見的應用程式安全問題，例如緩沖區溢出、使用未初始化記憶體、類型混淆和使用後釋放漏洞。這類缺陷在現代應用軟體的所有漏洞中占了很大比例。
相比之下，記憶體安全語言（最常見包括 Rust、Python、Java 和 Go）提供了如内置運作時和編譯時檢查等保護措施，以減輕常見的記憶體相關錯誤。
最近幾年，在政策引導下，不少大廠、項目确實開始發力使用記憶體安全的程式設計語言：
- 2021 年，由 AWS、華為、谷歌、微軟和 Mozilla 等創始成員支援，Rust 基金會成立。
- Linux 是從 2022 年 12 月開始合并 Rust 代碼。Linux 之父 Linus Torvalds 在去年 12 月出席 Open Source Summit Japan 2023 上透露：“Rust 一直在成長，但我們還沒有核心的任何部分真正依賴 Rust。對我來說，Rust 是技術上有意義的事情之一，但對我個人來說，更重要的是，作為核心和開發人員，我們不能停滞不前。”
- 盡管如此，Torvalds 繼續說道：“Rust 還沒有真正成為下一個偉大的事物。但我認為，在明年，我們将開始內建驅動程式，甚至一些主要的子系統也将開始積極使用 Rust。是以，要讓它成為核心的重要組成部分，還需要數年時間。但它肯定會成為核心的一部分。”
- 網際網路安全研究小組（ISRG）發起的 Prossimo 項目，它的目标是通過使用具有記憶體安全屬性的語言來解決 C 和 C++ 代碼中的記憶體安全問題，進而改善網際網路敏感的軟體基礎設施，而這種基礎設施的代表就是 Linux 核心。參與 Prossimo 項目的開發者們一直在用 Rust 重寫關鍵的開源庫，以減少遺留代碼中記憶體缺陷的風險。就在本周，Let’s Encrypt 表示它已經部署了 ntpd-rs，這是 Prossimo 用 Rust 重寫的網絡時間協定（NTP）守護程序。
同時，在這一趨勢下，Google 和微軟都開始向記憶體安全語言邁進，最初是用于新項目，最近則用于應用程式重寫。
不久前，Google 的工程總監 Lars Bergstrom 在倫敦的 Rust Nation UK 大會上分享了 Google 将 Go 或 C++ 編寫的項目遷移到 Rust 語言的經驗。他表示，「使用 Rust 的開發團隊相比于使用 C++ 的團隊，在工作效率上大約高出兩倍。」
對于另一大科技公司微軟，此前其 Windows 作業系統安全總監 David “dwizzle” Weston 透露，微軟正在用 Rust 程式設計語言重寫核心 Windows 庫。
遷移之路，任重而道遠
然而，鑒于将代碼庫完全用記憶體安全語言進行重寫這一任務過于複雜、成本高昂，是以僅想要通過政策的引導就能實作業界做出大規模的改變，顯然不太現實。
更何況為了應對記憶體安全程式設計語言的挑戰，争議之中的程式設計語言如 C++ 社群也正在嘗試通過 C++ 配置檔案使開發者能夠編寫更安全的代碼，這些配置檔案在編譯時提供安全保證。
針對這一點，CISA 在報告中也指出，還有很多工作需要完成。
“在性能和資源限制的地方，我們預計記憶體不安全的語言會繼續使用，包括作業系統核心和驅動程式、密碼學和網絡，尤其是嵌入式應用程式”，CISA 報告指出，“同時，即使在使用記憶體安全語言時，開發人員也可能禁用記憶體安全特性。AWS 在對‘開放源碼軟體安全資訊請求’的回應中，建議‘使用像 Rust 這樣的記憶體安全語言’編寫新代碼，但要注意并非所有名義上使用記憶體安全語言寫成的代碼實際上都是記憶體安全的...開發人員禁用使 Rust 記憶體安全的編譯器特性是容易的，而且相當普遍。”
是以，CISA 等組織也沒有特别好的辦法，隻是表示，“我們鼓勵其他人在此分析的基礎上進一步擴大我們對開源軟體記憶體不安全風險的集體了解，評估降低這種風險的方法（例如用記憶體安全語言有針對性地重寫關鍵元件），并繼續努力推動軟體制造商采取降低風險的行動。”
業界看法
對此，來自 Synopsys 軟體完整性小組技術經理 Gunnar Braun 表示，“該報告及其之前的‘記憶體安全路線圖指南’将這個問題送出給了公司 C 級高管——這是理所應當的。軟體安全與保障不再是純粹的技術問題。”
Braun 表示，許多開源程式運作在資源受限的嵌入式系統中。如果無法改變程式設計語言，那麼使用靜态代碼分析和模糊測試工具來降低記憶體安全風險就顯得尤為重要。
“一些記憶體安全語言，例如 Rust 或 Go，已經進入嵌入式系統，是以我樂觀地認為 C/C++ 終有一天會被大量取代——但不是今天，也不是明天，”他說道。
OpenSSF 總經理 Omkhar Arasaratnam 認為，「記憶體安全問題并不是開源或閉源軟體特有的問題。它是所有現代軟體的普遍問題。如今有許多記憶體安全的語言，比如 JavaScript、Python 和 Java，但軟體工程師經常使用記憶體不安全的舊語言，比如 C/C++，以實作性能或低級硬體通路。此外，盡管 Rust 近年來已成為低級系統程式設計中 C/C++ 的可行替代品，但有許多嵌入式系統和安全關鍵型應用程式并不适合 Rust。」
他補充道，“雖然用記憶體不安全的語言編寫記憶體安全的代碼是完全有可能的，但 25 年的 CVE 告訴我們，這種情況極不可能發生，這并不是說人們是糟糕的程式員，而是用記憶體不安全的語言編寫記憶體安全的代碼非常困難。”
在部分開發者看來，“這的确很好地提醒了我們，非記憶體安全的遺留語言不會消失。确實如此！雖然最好不要用低級語言編寫某些項目，但它們已經存在，重寫是一個巨大的工程，可能會引入其他邏輯錯誤。更好的開發方式是使用工具，并實際使用它們來修複一些關鍵的現有代碼。”
也有人認為：
“記憶體安全語言雖然被設計來減少記憶體洩漏的風險，但實際上仍然可能發生記憶體洩漏。有時候，像 C 語言（或 C++）往往會出現一些簡單的問題，但這些問題相對容易解決。當然，你仍然需要一個良好的測試套件來確定代碼品質，但一旦通過了類似 valgrind 的工具進行了記憶體清理，保持代碼在可控的範圍内并處理新的 Bug 相對較容易。
盡管不太熟悉 Rust，但 Java 程式員曾經在使用他們能找到的庫時遇到過問題。他們可能沒有充分了解自己使用的具體庫，是以可能會出現嚴重的記憶體洩漏問題。雖然他們的測試用例可能在他們自己的機器上運作正常，但對于企業級軟體來說，這些問題可能會倍增，過多的記憶體使用仍然可能導緻系統崩潰。”
在 AI 時代下，甚至有人建議，“與其用記憶體安全的程式設計語言重寫程式，倒不如可以讓 AI 幫忙捕捉一些安全漏洞。”
對此，你如何看待美國 CISA 等機構釋出的報告？程式設計語言安全性是否可以直接提升程式安全性？歡迎留言分享你的見解。
參考：
https://www.theregister.com/2024/06/28/cisa_open_source/
https://www.darkreading.com/application-security/cisa-memory-unsafe-code-open-source-projects
https://www.cisa.gov/sites/default/files/2024-06/joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf