Chrome安全團隊希望將指標錯誤消滅在編譯階段

語言: CN / TW / HK

在電腦保安領域,攻擊者的手段也在不斷創新。為了構築堅實的瀏覽器安全防線,谷歌已經為 Chrome 打造了基於沙箱和站點隔離的多程序架構。 不過在近日釋出的一篇部落格文章中,Chrome 安全團隊進一步介紹了他們在記憶體安全性方面的最新努力。

(來自:Google Security Blog

Chrome 安全團隊稱,儘管他們在努力堅守上述主要的安全防線,但模糊測試的結果表明,這些措施的防護效果已達到極限,意味著瀏覽器開發商無法再單純依靠單純的策略來抵禦野外攻擊。

資料表明,去年的時候,有超過 70% 的嚴重安全漏洞都與記憶體相關,尤其是 C / C++ 程式語言中的指標 bug 會導致記憶體誤解。在瀏覽器應用之外,記憶體安全也是一個需要全球軟體工程社群認真對待的問題。

與此同時,Chrome 安全團隊認為這也是一個機遇,畢竟許多 bug 都具有類似的根本原因,意味著我們能夠一次搞定大部分問題。為此,Chrome 安全團隊提出了三個著力點:

(1)在編譯時檢查指標是否正確;

(2)在執行時檢查指標是否正確;

(3)調查現有程式碼庫部分記憶體安全語言的使用。

“編譯時檢查”意味著在 Chrome 構建過程中確保安全,甚至早於向用戶裝置推送更新之前。

“執行時檢查”意味著 Chrome 瀏覽器會在終端裝置上執行軟體時進行檢查。當然,這麼做也會有一定的效能成本開銷。

考慮到有數百萬計的指標,即使每個指標的影響都極其細微,數十億的使用者量級,累加起來還是相當可觀的,尤其許多使用者仍在使用資源相對受限的低功耗移動裝置。

在理想情況下,Chrome 安全團隊傾向於優先選擇第(1)套方案。遺憾的是,C++ 程式語言在設計之初並沒有考慮到這一點。

權衡利弊之後,我們最終只剩下了讓 C++ 更安全(但也更慢)的第(2)和第(3)種選項,或嘗試開始使用其它程式語言。

換言之,Chrome 安全團隊將在 C++ 安全解決方案上傾注大量的心力,例如 MiraclePtr 和 ABSL / STL 強化模式。

在每種情況下,我們都希望消除相當一部分可被利用的安全漏洞,但預計也會造成一些效能損失。

比如藉助 MiraclePtr 隔離潛在會被引用的記憶體,以預防釋放後的隱患。而在記憶體資源更加寶貴的大部分移動裝置上,我們很難專門騰出一塊專門的隔離區。

即便如此,MiraclePtr 仍有望消除瀏覽器程序中超過 50% 的釋放後錯誤使用 —— 對於當前的 Chrome 安全性來說,這已經算得上是一個相當矚目的成就。

同時,Chrome 安全團隊將探索未來是否能夠把 Chrome 的某些部分用“記憶體安全語言”進行重構 —— 比如當前被寄予厚望的 Rust(由 Mozilla 僱員 Graydon Hoare 創立)。

由於 Rust 程式語言保障了編譯時的安全性,所以編譯器能夠早在程式碼抵達使用者裝置前排除指標錯誤,從而避免進一步的效能損失。至於 C++ 能否與 Rust 良好配合,仍有待時間去檢驗。