Google 工程师表示：目前 Chrome 代码库中所有严重的安全漏洞，70% 是内存管理的安全漏洞，其中 50% 的内存漏洞是 use-after-free 漏洞，因为对内存指针的错误管理，给予了攻击者攻击 Chrome 内部组件的机会。
近日，Google 工程师统计了 2015 年以来，Chrome 稳定分支中修复级别为 “high” 或 “critical” 的 912 个安全错误，结果发现约 70% 是内存安全漏洞。
事实上，不只是 Google，内存安全漏洞是很多科技公司都头疼的问题，微软工程师也曾公开表示：在过去 12 年中，微软产品的安全更新中，约有 70% 也是在解决内存安全漏洞。
为什么微软和 Google 的情况如此相似呢？因为它们代码库中使用的主要编程语言是 C 和 C++，由于 C 和 C++ 出现的时间较早，当时网络攻击还不是利用相关的威胁模型，大多数早期软件开发人员也没有考虑到相关的安全问题，所以 C 和 C++ 允许程序员完全控制管理应用程序的内存指针，出现基本的内存管理错误时，也没有相关的提示或者警告。
Chrome 的内存安全问题如何解决？
据了解，自 2019 年 3 月以来，在 130 个级别为 critical 的 Chrome 漏洞中，有 125 个是与内存相关的。这个数据也表明了，内存管理错误仍然是 Google 的一个大问题。
为了解决内存安全问题，Google 内部提出了一个 The Rule Of 2 原则，即为了保证安全性，程序员不能破坏两个以上的条件：
- 不可靠的输入：主要来自两个方面，一是 non-trivial 的语法，例如常用的 and 和 or，二是不安全的来源；
- 不安全的实现语言：即在编写程序时选择了缺乏内存安全性的语言，例如 C、C++、汇编语言等。目前内存安全的语言包括 Go、Rust、Python、Java、JavaScript、Kotlin 和 Swift 等。
- 高特权：特权最高的程序是计算机固件，引导加载程序、内核、系统管理程序或虚拟机监视器等；其次是操作系统级别的账户运行进程；特权较低的进程包括 GPU 进程和网络进程等。
“沙箱”也是 Google 用来解决安全问题的常用方法，Google 工程师会将数十个流程隔离到自己的沙箱中，并利用刚推出的“Site Isolation”功能，将每个站点的资源也放到沙箱中。同时，考虑到性能问题，Google 采用了沙箱化 Chrome 组件的方法，并在积极探索新的方法。
Google 表示将开发自定义 C++ 库，与 Chrome 代码库配合使用，以便更好地处理与内存相关的错误。并且有计划，在可能的情况下探索使用“内存安全”的编程语言，目前的候选对象包括 Rust、Swift、JavaScript、Kotlin 和 Java。
放弃 C 和 C++ 可行吗？
无论是 Google 还是微软，出现内存问题的根源是使用了诸如 C 和 C++ 这类的“不安全”编程语言，那么放弃 C 和 C++ 可行吗？
对企业来说，重新选择一种编程语言不是一件容易的事情，因为这意味着需要重写大量的代码，需要重新培训员工，需要招聘拥有新技能的员工。所以，放弃 C 和 C++ 不是一件容易的事情。
如果是全新的项目，我们完全可以选择一个内存安全的编程语言，无需考虑重写代码的风险。不过，还是需要改进测试或部署基础架构来支持新的编程语言。ChromeOS 的 CrosVM 就是采用的这种方法。
如果是现有项目的新组件，我们也可以选择内存安全的编程，例如 Rust、Swift 等编程语言都可以与 C、C++ 代码库互操作。不过，刚开始的投入可能会比较大，因为需要集成到构建系统中，所以需要使用一种新的语言在两种语言之间传递对象和数据构建抽象。Firefox 的新组件 WebAuthn 就是使用的这种方法。
以上两种情况的特点都是新代码与原有代码有明显的界限，无需重写代码，我们可以在构建新项目或新组件之后，再逐步处理现有代码。那如果是界限不明显、无法放弃 C 和 C++ 的情况，我们又该怎么办呢？
- 使用一些现代 C++ 习惯用法来生产更安全可靠的代码；
- 使用 fuzzers 和 sanitizers 提前发现错误；
- 使用 exploit mitigations 增加利用漏洞的难度；
- 特权分离，这样即使利用了漏洞，受影响的半径也较小。
来源：oschina
链接：https://my.oschina.net/u/4352624/blog/4295466