近日，有谷歌工程師分析了自 2015 年以來在 Chrome 穩定版分支中修復的 912 個安全錯誤。並發現，在這些被標記為“高”或“嚴重”等級的所有安全漏洞中，大約 70％ 是記憶體管理和安全問題。
這其中又有一半是 use-after-free 漏洞。這種安全問題是由對記憶體指標（地址）的錯誤管理引起的，為攻擊者開啟了攻擊 Chrome 內部元件的大門。
這一資料恰巧與微軟此前的研究結果相同：微軟安全響應中心（MSRC）對自 2004 年以來所有報告過的微軟安全漏洞進行了分類，所有微軟年度補丁中約有 70% 是針對記憶體安全漏洞的修復程式。
微軟安全響應中心曾給出解釋，這是因為他們大多數產品使用 C 和 C++ 編寫，而這兩種程式語言屬於“記憶體不安全”（memory-unsafe）的範疇。管理記憶體執行的開發人員程式碼中的一個漏洞可能導致一系列記憶體安全錯誤。
谷歌也面臨著相似的境地。僅僅從 2019 年 3 月到現在，等級為“嚴重”的 130 個 Chrome 漏洞中，有 125 個與記憶體損壞相關，可見記憶體管理仍然是一個很大的問題。
為此，谷歌工程師必須遵循 “2 的規則”（The Rule of 2）。即每當工程師編寫新的 Chrome 特性時，其程式碼不得破壞以下兩個以上的條件：
迄今為止，谷歌一直在 Chrome 中嘗試使用沙箱方法。他們將數十個程序隔離到自己的沙箱中，最近還推出了“站點隔離”功能，該功能將每個站點的資源也放入自己的沙箱程序中。但谷歌工程師表示，考慮到效能問題，他們使用沙盒化 Chrome 元件的方法已達到最大收益，現在必須尋求新的方法。
因此，谷歌計劃研究開發自定義 C++ 庫，以與 Chrome 的程式碼庫一起使用，這些庫可以更好地保護與記憶體相關的錯誤。
與此同時，谷歌還在探索 MiraclePtr 專案，該專案旨在將“use-after-free bug 轉變為具有可接受的效能、記憶體、二進位制大小和最小的穩定性影響的非安全崩潰”。
最後，值得注意的一點是，谷歌表示計劃在可能的情況下使用“安全”語言進行探索。候選物件包括 Rust、Swift、JavaScript、Kotlin 和 Java。
訊息來源：ZDNet
[admin
]
來源：OsChina
連結：https://www.oschina.net/news/115898/chrome-70-of-all-security-bugs-are-memory-safety-issues
谷歌工程師：Chrome 70% 的安全漏洞是記憶體安全問題，Rust 又成備選語言已經有192次圍觀
