整理 | 蘇宓
出品 | CSDN（ID：CSDNnews）
如同微軟想盡辦法讓消費者盡可能地升級到最新的 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
推薦閱讀：
由 CSDN 和 Boolan 聯合主辦的「2024 全球軟體研發技術大會（SDCon）」將於 7 月 4 -5 日在北京威斯汀酒店舉行。
由世界著名軟體架構大師、雲原生和微服務領域技術先驅 Chris Richardson 和 MIT 電腦與 AI 實驗室(CSAIL)副主任，ACM Fellow Daniel Jackson 領銜，BAT、微軟、字節跳動、小米等技術專家將齊聚一堂，共同探討軟體開發的最前沿趨勢與技術實踐。
