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++和新语言时会有一些麻烦。