|
如果說此前 Kotlin、Dart、Julia、Carbon 等后起之秀向老牌編程語言發(fā)起挑戰(zhàn)進(jìn)攻都是小打小鬧，那么這一次 C、C++ 這幾種常青藤編程語言則是真實(shí)地陷入了尷尬的境地。 近日，美國國家安全局（NSA）發(fā)布了最新的指南，鼓勵(lì)多個(gè)組織將編程語言從 C/C++ 轉(zhuǎn)為使用內(nèi)存安全的語言，如 C#、Rust、Go、Java、Ruby 和 Swift，主要原因是這樣可以幫助軟件開發(fā)者和使用者預(yù)防并緩解軟件內(nèi)存安全問題，這些問題占可利用漏洞的很大一部分。  安全的第一大“殺手”——內(nèi)存漏洞 一直以來，內(nèi)存安全的漏洞引起多個(gè)企業(yè)與開發(fā)者的警覺。 根據(jù)長期關(guān)注內(nèi)存漏洞的開發(fā)者 @LazyFishBarrel 的統(tǒng)計(jì)，蘋果公司的 iOS 和 macOS 系統(tǒng)中 60%-70% 的漏洞是內(nèi)存安全漏洞。  微軟在 2019 年的一次會(huì)議上透露，從 2006 年到 2018 年，其發(fā)現(xiàn)的 70% 的漏洞都是因內(nèi)存安全問題造成的。  據(jù) Google 估計(jì)，Chrome 中存在了類似比例的內(nèi)存安全漏洞，另外 90% 的 Android 系統(tǒng)漏洞也都是內(nèi)存安全問題。 為此，NSA 認(rèn)為，黑客極有可能會(huì)利用代碼中管理不善的內(nèi)存漏洞，而這種漏洞在程序員使用靈活性更高的編程語言時(shí)更容易出現(xiàn)。于是，其最新發(fā)布了《軟件內(nèi)存安全之網(wǎng)絡(luò)安全信息指南》時(shí)，寫道，「黑客可以利用這些漏洞進(jìn)行遠(yuǎn)程代碼執(zhí)行或其他不利影響，這通常會(huì)危及設(shè)備，并且成為大規(guī)模網(wǎng)絡(luò)入侵的第一步」，因此 NSA 建議各個(gè)組織盡可能使用內(nèi)存安全語言，并通過代碼強(qiáng)化防御（如編譯器選項(xiàng)、工具選項(xiàng)和操作系統(tǒng)配置）來增強(qiáng)保護(hù)。 NSA 網(wǎng)絡(luò)安全技術(shù)總監(jiān) Neal Ziring 表示，在開發(fā)消除此類漏洞的軟件時(shí)，必須始終使用內(nèi)存安全語言和其他保護(hù)措施。  C、C++ 成為重災(zāi)區(qū) 在 NSA 看來，我們常用的編程語言如 C 和 C++，在內(nèi)存管理方面提供了很大的自由度和靈活性，但用這種語言開發(fā)的應(yīng)用程序的安全性很大程度上需要依賴程序員的測(cè)試、檢測(cè)環(huán)節(jié)。 不過，只要程序員自身稍微有些疏忽，簡(jiǎn)單的 Bug 也會(huì)帶來嚴(yán)重的內(nèi)存漏洞。 雖然當(dāng)前行業(yè)中有很多軟件分析工具能夠檢測(cè)到許多內(nèi)存管理問題，操作環(huán)境選項(xiàng)也可以提供一些保護(hù)，但內(nèi)存安全軟件語言所提供的固有保護(hù)可以防止或減輕大多數(shù)內(nèi)存管理問題。 針對(duì)這一問題，幾年前，微軟云開發(fā)推廣部的 Ryan Levick 在分享微軟為什么要從 C/C++ 轉(zhuǎn)向 Rust 時(shí)，也曾直言，「無論軟件公司在工具和人員的培訓(xùn)上投入多少精力也不能解決問題，因?yàn)?C++ 本質(zhì)上就不是安全的語言」。他表示：“我們使用的語言由于年代久遠(yuǎn)、來自不同時(shí)代，無法為我們提供保護(hù)，讓我們免受此類漏洞攻擊。C++ 不是一種內(nèi)存安全的語言，相信這一點(diǎn)無人有異議?！?/p> 近日來，微軟 Azure CTO Mark Russinovich 也再次呼吁，「是時(shí)候停止使用 C/C++ 啟動(dòng)任何新項(xiàng)目」。 然而，眾所周知，C 和 C++ 是編寫核心系統(tǒng)軟件的默認(rèn)語言。這兩門編程語言速度快，而且源代碼可以直接匯編成機(jī)器語言。 雖然一邊有很多企業(yè)高管呼吁不要用，但另一邊也有很多人不信邪，不愿相信 C、C++ 語言的不足之處。 為此，有人稱，“只要你不使用從 C 繼承的任何功能，C++ 就是安全的”，亦或者“只要遵從現(xiàn)代 C++ 的類型和管用做法，就不會(huì)引發(fā)內(nèi)存方面的漏洞”。針對(duì)這一爭(zhēng)論，科技圈中有開發(fā)者現(xiàn)身說法，根據(jù)自身在大型 C++ 項(xiàng)目上（遵從現(xiàn)代的慣用做法）的開發(fā)經(jīng)驗(yàn)，發(fā)表了《現(xiàn)代 C++ 救不了程序員》一文，用實(shí)例證明 C++ 提供的類型完全不能阻止漏洞的泛濫。 另外，也有人提出質(zhì)疑，“為什么非要棄用 C、C++ 呢，有什么理由不能在 C、C++ 編譯器中強(qiáng)制執(zhí)行內(nèi)存安全嗎？” 針對(duì)這一點(diǎn)，有開發(fā)者進(jìn)行回應(yīng)： 這在以前就已經(jīng)嘗試過了。 但挑戰(zhàn)是雙重的。首先，如果在編譯器強(qiáng)制執(zhí)行內(nèi)存安全，范圍也只能局限在編譯器上。然而，真正的內(nèi)存安全實(shí)際上是（至少）線程安全、空值安全和類型安全，以及大多數(shù)人所想的原始邊界檢查等各個(gè)方面。除非你打算進(jìn)入托管語言領(lǐng)域（Managed Language）并引入 GC，否則你需要語言級(jí)別的結(jié)構(gòu)來允許程序員在這些新的邊界內(nèi)有效工作。例如，在 Rust 中，這就是 '所有權(quán) '系統(tǒng)。 第二點(diǎn)是，如果總是把語言功能限制在一些有限的、更安全的范圍內(nèi)，或者用一些自定義的東西取代核心功能（例如 malloc 或編譯器）。這就把你能使用的庫限制在那些使用功能集的庫上，并要求你無限期地維護(hù)這些核心功能。即便如此，你也不會(huì)得到 '真正的 '安全，因?yàn)檫@取決于每個(gè)人都很小心、不使用錯(cuò)誤的功能、編譯器，而你又非常確定你的核心實(shí)現(xiàn)本身是安全的。 因此，如果你全力以赴，與其需要一個(gè)特定的編譯器，再加上一套不同的核心語言特性，再加上你需要確保所有的支持庫都符合要求，再加上需要為靜態(tài)分析和編譯工具鏈定制支持工具，倒不如直接用一種新的語言，Rust 便是不錯(cuò)的選擇。   Rust 是未來，但任重而道遠(yuǎn) 「棄用 C、C++，扶持 Rust」的爭(zhēng)論經(jīng)過幾年的發(fā)酵持續(xù)到現(xiàn)在，愈演愈烈。與此同時(shí)，推動(dòng)軟件開發(fā)向使用內(nèi)存安全語言發(fā)展的隊(duì)伍也從最初微軟、Google、亞馬遜等大廠的倡議，逐漸拓展到具體的開發(fā)者們以及學(xué)術(shù)界，現(xiàn)如今也包括了 NSA 在列。 NSA 表示，使用內(nèi)存安全語言可以幫助防止程序員引入某些類型的內(nèi)存相關(guān)問題。 內(nèi)存是作為計(jì)算機(jī)語言的一部分自動(dòng)管理的，它不依賴于程序員添加代碼來實(shí)現(xiàn)內(nèi)存保護(hù)。內(nèi)存管理通常是使用編譯和運(yùn)行時(shí)檢查機(jī)制來實(shí)時(shí)自動(dòng)保護(hù)。使用更加安全的語言，如 C#、Go、Java、Ruby、Rust、和 Swift 等語言，可以一定程度上保護(hù)程序員不會(huì)無意中引入內(nèi)存管理錯(cuò)誤。 不過，羅馬并非一日之功。 要想用 Rust 將 C、C++ 取而代之，也需要很長的一段時(shí)間，為此 C++ 之父 Bjarne Stroustrup 在回應(yīng) C++ 與 Rust 之爭(zhēng)時(shí)分享道，“直接替換 C++ 代碼，或者讓它們變得更加安全都是一項(xiàng)非常艱巨的任務(wù)，需要逐步慢慢地才能做到這一點(diǎn)。否則大量不安全的 C++ 代碼將會(huì)永遠(yuǎn)存在?！?/p> 網(wǎng)絡(luò)安全公司 Acronis 的 CISO Kevin Reed 在接受外媒 The Register 采訪時(shí)也說道，“多年來，使用 C 和 C++ 編寫的代碼數(shù)量巨大，即使我們明天都開始使用 Rust 和 Go，也需要幾十年的時(shí)間才能清理這個(gè)爛攤子?！?/p> 參考資料： https:///2021/12/13/apple-memory-safety/ https://www./2022/11/11/nsa_urges_orgs_to_use/ https://www./Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/ https://media./2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF  |
|
|
