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++和新語言時會有一些麻煩。


Advertisement

更多 iThome相關內容