近日，有谷歌工程师分析了自 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 特性时，其代码不得破坏以下两个以上的条件：

• 该代码处理不可信的输入

• 代码在没有沙箱的情况下运行

• 代码使用不安全的编程语言（C/C ++）编写

迄今为止，谷歌一直在 Chrome 中尝试使用沙箱方法。他们将数十个进程隔离到自己的沙箱中，最近还推出了“站点隔离”功能，该功能将每个站点的资源也放入自己的沙箱进程中。但谷歌工程师表示，考虑到性能问题，他们使用沙盒化 Chrome 组件的方法已达到最大收益，现在必须寻求新的方法。

因此，谷歌计划研究开发自定义 C++ 库，以与 Chrome 的代码库一起使用，这些库可以更好地保护与内存相关的错误。

与此同时，谷歌还在探索 MiraclePtr 项目，该项目旨在将“use-after-free bug 转变为具有可接受的性能、内存、二进制大小和最小的稳定性影响的非安全崩溃”。

最后，值得注意的一点是，谷歌表示计划在可能的情况下使用“安全”语言进行探索。候选对象包括 Rust、Swift、JavaScript、Kotlin 和 Java。

文章转载自 OSCHINA 社区 [http://www.oschina.net]

求分享转发： 分享到QQ空间 分享给QQ好友