我們為何需要更安全的系統編程語言？

編程語言數百種，哪種才是最安全的？

作者 | 微軟安全響應中心

譯者 | 彎月，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

此前我們討論過主動解決內存安全問題的必要性。顯然僅通過工具和指導無法阻止這類漏洞。十多年來，內存安全問題與CVE（常見漏洞披露）的比例非常接近。我們認為，使用內存安全語言可以通過工具和培訓無法實現的方式來緩解這種情況。

在這篇文章中，我們將探討一些真實的微軟產品漏洞示例（經過測試和靜態分析），這些漏洞可以通過使用內存安全語言來防止。

內存安全

內存安全是編程語言的一種特性，在擁有內存安全的編程語言中，所有的內存訪問都有明確的定義。目前使用的大多數編程語言都通過某種形式的垃圾回收實現了內存安全。然而，無法承受垃圾收集器那般繁重的運行時的系統級語言（即用於構建其他軟體所依賴的底層系統的語言，比如OS內核、網路棧等）通常都不是內存安全的。

微軟修復並指定了CVE的安全漏洞中，大約70%的根本原因都是內存安全問題。儘管我們採取了緩解措施，包括嚴格的代碼審查、培訓、靜態分析等等。

微軟70%的漏洞仍然是內存安全問題

雖然許多有經驗的程序員可以編寫正確的系統級代碼，但很明顯無論採用何種緩解措施，使用傳統的系統級編程語言編寫內存安全的代碼幾乎是不可能的。

下面，讓我們看一些現實生活中由於使用沒有內存安全保證的語言而引發的安全漏洞的例子。

空間內存安全

空間內存安全指的是確保所有內存訪問都位於被訪問類型的邊界內。為此需要代碼來跟蹤這些大小，並根據這些大小正確檢查所有的內存操作。

控制流的極端情況下可能漏掉檢查，或者由於沒有考慮到整數符號、整數提升或整數溢出的複雜性而錯誤地實現檢查。讓我們看看如下Microsoft Edge的這個例子，由Alexandru Pitis發現（CVE-2018-8301）：

[0]處的檢查是正確的。但是，[1]可以修改字元串的大小，使得獲取的偏移量失效。這就導致[2]處調用複製函數時使用了與預期不同的偏移量，導致了越界寫入。

該漏洞的修復很簡單：將「偏移檢查」移動到距離使用時更近的地方。問題在於，複雜的代碼庫中很容易出現這個錯誤，而且簡單地重構代碼也可能會再次引發這個漏洞。現代C++提供了span來強制執行數組訪問的邊界檢查。然而，不幸的是這不是默認值，所以是否使用span完全依賴於開發人員。因此在實踐中很難強制使用這種結構。

如果編程語言能夠自動跟蹤和驗證大小，那麼程序員就不必再擔心正確實現這些檢查，而我們也可以確定我們的代碼中不存在這些問題。

時間內存安全

時間內存安全指的是確保指針在解引用時仍然指向有效的內存。

一個常見的模式就是釋放後使用，該漏洞的觸發方法是，首先對某個內存取引用後保存到局部指針中，然後執行一系列複雜的操作，這些操作可能會釋放或移動該內存，導致局部指針中的引用過時，然後在引用失效後進行解引用。例如Steven Hunter發現的Edge的源代碼示例（CVE-2017-8596）：

這個錯誤的原因是，太多的複雜API互相交互，程序員無法強制整個代碼中的內存所有權。在[0]處，程序獲取指向JavaScript對象擁有的對象指針。然後在[1]處，由於語言的複雜性，代碼需要執行更多的JavaScript代碼才能獲取另一個變數。在[2]出，它會使用該緩衝區和寬度，使用該指針的內容來創建新的JavaScript對象。

問題在於：

1. 程序同時使用了垃圾回收和手動內存管理。垃圾回收器會跟蹤JavaScript對象，但它並不知道是否有指針指向對象的內部。

2. 由於VarToInt重入了JavaScript，JS程序可以修改狀態，並清除在[1]處創建過別名的那個指針的所有權。

這個漏洞與迭代器失效bug類似，當狀態被修改時，所有指向JavaScript內部狀態的指針都可能變成無效指針。但是在瀏覽器這樣複雜的程序中，用靜態方式來確保不發生該bug幾乎不可能。該問題的根源在於給指向可修改狀態的指針添加別名。C和C++沒有相應的工具來防止這種錯誤。但是，我們建議始終使用「智能指針」來跟蹤內存所有權。

數據競爭條件

當同一個進程中的兩個或多個線程同時訪問同一個內存地址，且至少有一個訪問是寫操作，而且線程沒有使用任何明確的鎖操作來控制對該內存的訪問時，就會發生數據競爭。在多線程訪問共享數據的情況下，保持空間和時間的內存安全變得更加困難，而且更易於出錯。即使只在非常小的一段時間內共享沒有同步的內存，也有可能被其他線程修改數據，而被修改的數據正是引用其他內存地址的數據。這就是檢查時/使用時（TOCTOU）漏洞的原因之一，其會導致空間和時間內存安全漏洞。

Jordan Rabet在Blackhat 2018上披露的VMSwitch漏洞演示了數據競爭可能造成的影響。這段代碼在虛擬機給宿主發送特定消息時被調用。這意味著，它可以以並行方式調用，來處理其他控制消息和數據包。這樣做是有問題的，因為控制消息的處理函數使用的信息在被修改時沒有進行任何鎖操作[0]。

下面這段代碼被多個控制消息處理函數使用，從中可以看出被更新的信息被使用的過程：

由於未同步的訪問，新的緩衝區可能被舊的opHostData->AllocatedRanges [1]的值使用，導致越界寫操作[3]。

防止此類漏洞需要對多個線程訪問的數據結構進行加鎖操作，直到數據處理完成。但是，在C++中並沒有容易的靜態檢查方法來強制這一點。

我們該怎麼辦

解決本文提出的幾個問題需要幾種不同的度量。C++中的「現代」結構（如span<T>）至少可以防止某些類型的內存安全問題，而其他的現代C++特性（如智能指針）應當儘可能使用。但是，現代C++依然不是完全內存安全、完全沒有數據競爭的語言。更糟糕的是，這些特性使用與否，完全依賴於程序員「做正確的事情」，在大型、模糊的代碼庫中幾乎不可能強制這一點。C++也沒有能夠用安全的抽象來包裹不安全代碼的工具，意味著儘管在局部可以強制正確的編程習慣，但用C或C++構建安全的組件將極其困難。

除此之外，軟體還應當儘可能轉移到完全內存安全的語言，如C#或F#等通過運行時檢查和垃圾回收來保證內存安全的語言。畢竟，除非必要，否則不應當涉足複雜的內存管理。

如果出於速度、控制和可預測性等合理的理由而使用C++，那麼可以考慮轉移到內存安全的系統編程語言上。下一篇文章我們將介紹為什麼我們認為Rust是目前最合適的編程語言，因為它能夠以內存安全的方式編寫系統級的程序。

原文：https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

本文為 CSDN 翻譯，轉載請註明來源出處。

【END】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！