Chromium專案中的70%安全缺陷是記憶體安全問題

Chromium專案研究人員經研究發現，專案中的所有高嚴重性安全漏洞，其中有70％來自於記憶體安全漏洞，也就是由C/C++指標操作錯誤所造成，而這些錯誤中又有一半是釋放後使用（Use-After-Free）的臭蟲。

這個結果來自於對2015年以來，Chromium的912個高或嚴重安全性臭蟲，對穩定版本所造成影響的研究，這些臭蟲平均分布在程式碼庫中，並且其中有一大部分非穩定性錯誤，是由同樣類型原因造成，這些漏洞讓使用者暴露在風險之中，同時還增加了修補和交付Chrome的成本。

雖然Chromium的安全基礎架構的設計，便是預設程式碼庫存在這些臭蟲，並用沙盒降低臭蟲所產生的傷害，但研究人員提到，這並非解決問題的根本之道。Chromium會用沙盒執行程式碼，當其中臭蟲遭到利用，便可以防止駭客接管主機，在過去幾年，Chromium一再強化了安全基礎架構，確保網站相互隔離，而這些工作也確保Chromium能夠走在攻擊者之前，讓Chromium免於嚴重的安全威脅。

但是研究人員認為，Chromium已經達到了沙盒和網站隔離的極限，其中最重要的限制是，雖然程序是隔離的最小單位，但是以程序進行隔離的成本並不低，尤其是在Android上，過多的程序會影響裝置運作狀況，有可能使像是其他應用程式或是瀏覽器的分頁籤等後臺程序，被終止的頻率變高。

目前仍有程序共用多個網站的資訊，像是由C++編寫的網路服務，就是一個大型元件，用來解析來自網路上各種複雜的輸入，根據Chromium的開發第二規則，網路服務是一個大型且易受攻擊的目標，具有許多嚴重的漏洞，落在毀滅區間（Doom Zone）中。

要用網站隔離的想法來處理網路服務為不可能的任務，雖然當把每個網路服務程序都綁定單一網站，會大大提升網路服務的安全性，但這也會使Chromium程序數量激增，進而嚴重影響效能。研究人員表示，在堅持第二規則的情況下，會衝擊Chrome新功能的開發，因為要啟動一個新的程序來處理不可信資料的成本太高。

研究人員指出，現在已經無法從更多程序或是更強大的沙盒，來抵禦攻擊者新型的攻擊，而成本最低的做法，便是從源頭減少錯誤。因此Chromium專案研究人員正著手研究，採取解決記憶體不安全問題的所有必要手段，包括自定義C++函式庫，加入硬體緩解方案，並在適當的地方使用更安全的語言。

總結主要方法的兩個方向，其一是大幅更改C++的開發方法，像是禁止使用原始指標等，但這些作法可能連帶影響程式效能，另一個方向，則是為程式語言設計編譯時的安全檢查，雖然對效能的影響較小，但是在橋接C++和新語言時會有一些麻煩。