對(duì)于系統(tǒng)編程語(yǔ)言應(yīng)該是越安全越好

編程語(yǔ)言數(shù)百種，哪種才是最安全的？

此前我們討論過(guò)主動(dòng)解決內(nèi)存安全問(wèn)題的必要性。顯然僅通過(guò)工具和指導(dǎo)無(wú)法阻止這類(lèi)漏洞。十多年來(lái)，內(nèi)存安全問(wèn)題與CVE（常見(jiàn)漏洞披露）的比例非常接近。我們認(rèn)為，使用內(nèi)存安全語(yǔ)言可以通過(guò)工具和培訓(xùn)無(wú)法實(shí)現(xiàn)的方式來(lái)緩解這種情況。

內(nèi)存安全是編程語(yǔ)言的一種特性，在擁有內(nèi)存安全的編程語(yǔ)言中，所有的內(nèi)存訪問(wèn)都有明確的定義。目前使用的大多數(shù)編程語(yǔ)言都通過(guò)某種形式的垃圾回收實(shí)現(xiàn)了內(nèi)存安全。然而，無(wú)法承受垃圾收集器那般繁重的運(yùn)行時(shí)的系統(tǒng)級(jí)語(yǔ)言（即用于構(gòu)建其他軟件所依賴(lài)的底層系統(tǒng)的語(yǔ)言，比如OS內(nèi)核、網(wǎng)絡(luò)棧等）通常都不是內(nèi)存安全的。

微軟修復(fù)并指定了CVE的安全漏洞中，大約70%的根本原因都是內(nèi)存安全問(wèn)題。盡管我們采取了緩解措施，包括嚴(yán)格的代碼審查、培訓(xùn)、靜態(tài)分析等等。雖然許多有經(jīng)驗(yàn)的程序員可以編寫(xiě)正確的系統(tǒng)級(jí)代碼，但很明顯無(wú)論采用何種緩解措施，使用傳統(tǒng)的系統(tǒng)級(jí)編程語(yǔ)言編寫(xiě)內(nèi)存安全的代碼幾乎是不可能的。

該漏洞的修復(fù)很簡(jiǎn)單：將“偏移檢查”移動(dòng)到距離使用時(shí)更近的地方。問(wèn)題在于，復(fù)雜的代碼庫(kù)中很容易出現(xiàn)這個(gè)錯(cuò)誤，而且簡(jiǎn)單地重構(gòu)代碼也可能會(huì)再次引發(fā)這個(gè)漏洞。現(xiàn)代C++提供了span來(lái)強(qiáng)制執(zhí)行數(shù)組訪問(wèn)的邊界檢查。然而，不幸的是這不是默認(rèn)值，所以是否使用span完全依賴(lài)于開(kāi)發(fā)人員。因此在實(shí)踐中很難強(qiáng)制使用這種結(jié)構(gòu)。

如果編程語(yǔ)言能夠自動(dòng)跟蹤和驗(yàn)證大小，那么程序員就不必再擔(dān)心正確實(shí)現(xiàn)這些檢查，而我們也可以確定我們的代碼中不存在這些問(wèn)題。時(shí)間內(nèi)存安全指的是確保指針在解引用時(shí)仍然指向有效的內(nèi)存。

這個(gè)錯(cuò)誤的原因是，太多的復(fù)雜API互相交互，程序員無(wú)法強(qiáng)制整個(gè)代碼中的內(nèi)存所有權(quán)。在[0]處，程序獲取指向JavaScript對(duì)象擁有的對(duì)象指針。然后在[1]處，由于語(yǔ)言的復(fù)雜性，代碼需要執(zhí)行更多的JavaScript代碼才能獲取另一個(gè)變量。在[2]出，它會(huì)使用該緩沖區(qū)和寬度，使用該指針的內(nèi)容來(lái)創(chuàng)建新的JavaScript對(duì)象。

程序同時(shí)使用了垃圾回收和手動(dòng)內(nèi)存管理。垃圾回收器會(huì)跟蹤JavaScript對(duì)象，但它并不知道是否有指針指向?qū)ο蟮膬?nèi)部。由于VarToInt重入了JavaScript，JS程序可以修改狀態(tài)，并清除在[1]處創(chuàng)建過(guò)別名的那個(gè)指針的所有權(quán)。這個(gè)漏洞與迭代器失效bug類(lèi)似，當(dāng)狀態(tài)被修改時(shí)，所有指向JavaScript內(nèi)部狀態(tài)的指針都可能變成無(wú)效指針。但是在瀏覽器這樣復(fù)雜的程序中，用靜態(tài)方式來(lái)確保不發(fā)生該bug幾乎不可能。該問(wèn)題的根源在于給指向可修改狀態(tài)的指針添加別名。C和C++沒(méi)有相應(yīng)的工具來(lái)防止這種錯(cuò)誤。但是，我們建議始終使用“智能指針”來(lái)跟蹤內(nèi)存所有權(quán)。

當(dāng)同一個(gè)進(jìn)程中的兩個(gè)或多個(gè)線程同時(shí)訪問(wèn)同一個(gè)內(nèi)存地址，且至少有一個(gè)訪問(wèn)是寫(xiě)操作，而且線程沒(méi)有使用任何明確的鎖操作來(lái)控制對(duì)該內(nèi)存的訪問(wèn)時(shí)，就會(huì)發(fā)生數(shù)據(jù)競(jìng)爭(zhēng)。在多線程訪問(wèn)共享數(shù)據(jù)的情況下，保持空間和時(shí)間的內(nèi)存安全變得更加困難，而且更易于出錯(cuò)。即使只在非常小的一段時(shí)間內(nèi)共享沒(méi)有同步的內(nèi)存，也有可能被其他線程修改數(shù)據(jù)，而被修改的數(shù)據(jù)正是引用其他內(nèi)存地址的數(shù)據(jù)。這就是檢查時(shí)/使用時(shí)（TOCTOU）漏洞的原因之一，其會(huì)導(dǎo)致空間和時(shí)間內(nèi)存安全漏洞。

Jordan Rabet在Blackhat 2018上披露的VMSwitch漏洞演示了數(shù)據(jù)競(jìng)爭(zhēng)可能造成的影響。這段代碼在虛擬機(jī)給宿主發(fā)送特定消息時(shí)被調(diào)用。這意味著，它可以以并行方式調(diào)用，來(lái)處理其他控制消息和數(shù)據(jù)包。這樣做是有問(wèn)題的，因?yàn)榭刂葡⒌奶幚砗瘮?shù)使用的信息在被修改時(shí)沒(méi)有進(jìn)行任何鎖操作[0]。

解決本文提出的幾個(gè)問(wèn)題需要幾種不同的度量。C++中的“現(xiàn)代”結(jié)構(gòu)（如span）至少可以防止某些類(lèi)型的內(nèi)存安全問(wèn)題，而其他的現(xiàn)代C++特性（如智能指針）應(yīng)當(dāng)盡可能使用。但是，現(xiàn)代C++依然不是完全內(nèi)存安全、完全沒(méi)有數(shù)據(jù)競(jìng)爭(zhēng)的語(yǔ)言。更糟糕的是，這些特性使用與否，完全依賴(lài)于程序員“做正確的事情”，在大型、模糊的代碼庫(kù)中幾乎不可能強(qiáng)制這一點(diǎn)。C++也沒(méi)有能夠用安全的抽象來(lái)包裹不安全代碼的工具，意味著盡管在局部可以強(qiáng)制正確的編程習(xí)慣，但用C或C++構(gòu)建安全的組件將極其困難。

除此之外，軟件還應(yīng)當(dāng)盡可能轉(zhuǎn)移到完全內(nèi)存安全的語(yǔ)言，如C#或F#等通過(guò)運(yùn)行時(shí)檢查和垃圾回收來(lái)保證內(nèi)存安全的語(yǔ)言。畢竟，除非必要，否則不應(yīng)當(dāng)涉足復(fù)雜的內(nèi)存管理。如果出于速度、控制和可預(yù)測(cè)性等合理的理由而使用C++，那么可以考慮轉(zhuǎn)移到內(nèi)存安全的系統(tǒng)編程語(yǔ)言上。