一直以來，網路瀏覽器都會受到來自黑客的攻擊，谷歌曾試圖用沙箱解決這個問題，但由於效能問題進展受阻。因此，近日 Chrome 安全團隊發文宣佈正在考慮使用記憶體安全語言 Rust 重寫或開發 Chrome 的部分模組。
眾所周知，記憶體安全是全球軟體工程界都需要認真對待的問題。有資料顯示，去年 Chrome 工程師們分析了自 2015 年以來 Chrome stable 分支中修復的 912 個安全漏洞，這些漏洞的嚴重性評級為“高”或“嚴重”，而這些嚴重安全漏洞裡，有 70% 以上都是記憶體安全問題。也就是說，C 或 C++ 語言中的指標錯誤會導致記憶體被誤解。
Chrome安全團隊表示，儘管與黑盒測試技術相結合仍是 Chrome 的主要“防線”，但這似乎已經達到了極限，再也無法靠這一個策略來抵抗住瘋狂的攻擊。
Chrome 安全團隊認為，記憶體安全問題的存在，對於團隊來說既是挑戰也是機會，因為許多 bug 都有相同的根源，這意味著他們可以在一個步驟中消除大部分 bug。
對此，Chrome 安全團隊一直在探索，並通過以下 3 大途徑來解決：
- 通過編譯時檢查指標是否正確，使 C++ 更安全。
- 通過執行時檢查指標是否正確，使 C++ 更安全。
- 調查部分程式碼庫使用記憶體安全語言的情況。
“編譯時檢查”，意味著在 Chrome 構建過程中或 在 Chrome 進入使用者裝置前，安全就得到了保證。而“執行時”是指 Chrome 安全團隊在使用者的裝置上執行 Chrome 時進行檢查，由於“執行時檢查”會導致效能損失（儘管檢查指標的正確性在記憶體和 CPU時間上的消耗是微乎其微的，如果有數百萬個指標加起來的話會加劇影響），且 Chrome 的效能對數十億使用者非常重要，許多使用者使用的是沒有太多記憶體的低功耗移動裝置，因此這些檢查的增加將導致網路速度變慢。
所以在理想情況下，Chrome 會選擇以上 3 個途徑的選項1——在編譯時使C++更安全。但不幸的是，語言理念並非這樣設計的。所以 Chrome 也有了選項 2 和 選項3——使C++更安全（但速度較慢），或開始使用不同的語言（Chrome Security正在試驗這兩種方法。）
同時，Chrome 安全團隊還介紹了其在 C++ 安全解決方案方面的重大投資——如 PTR 和ABSL/STL 強化模式。在每種情況下，Chrome 都希望消除可利用的安全漏洞中相當大的一部分，但他們也預料到了一些效能損失。
同時，Chrome 安全團隊還將探索未來是否可以為 Chrome 的某些部分使用記憶體安全語言，比極具競爭力的Rust 語言，（很大程度上）是編譯時安全的。也就是說，Rust 編譯器在程式碼到達使用者裝置之前就發現了指標錯誤，因此沒有效能損失。然而，關於 Chrome 是否能夠使 C++ 和 Rust 充分協同工作，還有一些懸而未決的問題。即使 Chrome 明天就開始在 Rust 中編寫新的大型元件，Chrome 也不可能在幾年內就能把大部分大部分安全漏洞給全部消除。所以能否讓語言邊界足夠乾淨，以便可以使用 Rust 編寫部分現有元件？Chrome 安全團隊 暫時也無法回答這個問題。
對於開發者團隊來說，安全與漏洞就像是“貓鼠遊戲”，隨著攻擊者的不斷“創新”，瀏覽器也必須要安裝新的防禦系統才能保持領先。儘管 Chrome 已在沙箱和站點隔離基礎上，投資建立了更強大的多程式體系結構，但有時也是防不勝防。
目前，Chrome 安全團隊已經開始在 Chrome 原始碼樹中進行有限的、非面向使用者的 Rust 實驗，由於目前還處於試驗階段，因此暫未在 Chrome 的生產版本中使用。
參考連結：