放弃 C/C++，它太不安全了，美国 CISA 等多家机构联合警告！

在编程语言界，每当提及「安全」一词时，很多人无形之中便将 C、C++ 划在围城之外。

继去年美国国家安全局（NSA）发出预警之后，12 月 6 日，美国网络安全和基础设施局 (CISA)也开始联合 NSA、美国联邦调查局 (FBI) 以及澳大利亚、加拿大、英国和新西兰的网络安全机构发布了一份 23 页的《内存安全路线图指南》，呼吁软件开发商需要采用越来越多的新编程语言来保护内存，以减少其产品中的安全漏洞数量。

其中，该指南还点名指出 C 和 C++ 是内存不安全的语言代表，软件开发商应该放弃使用，从而迅速采用 Rust、C#、Go、Java、Python 和 Swift 等其他内存安全编程语言 (MSL)。

1、深受内存安全漏洞困扰的各大科技公司

所谓的内存安全错误，是指缓冲区溢出、未初始化内存、类型混淆和释放后使用（Use After Free）等缺陷。利用这些漏洞的攻击者通常可以接管受影响的系统，窃取数据或运行任意代码。

根据各大科技公司发布的漏洞分析报告显示，过去几十年来，内存安全漏洞占比要比我们想象的要高很多：

微软时任安全响应中心的安全工程师 Matt Miller 在 2019 年的一次会议上分享道，从 2006 到 2018 年，微软每年 CVE 的漏洞中约 70% 是内存安全问题。其透露，大多数已修复并分配了 CVE 的漏洞都是由开发人员无意中在 C 和 C++ 代码中插入内存损坏漏洞造成的。随着微软代码库的增加以及在代码中使用更多开源软件，这个问题不仅没有得到改善，反而越来越严重。
在 Google Chromium 项目发现的漏洞中，约 70% 严重性安全错误是内存不安全问题（即 C/C++ 指针错误）；
在对 Mozilla 漏洞的分析中，34 个严重/高度错误中有 32 个是内存安全漏洞；
根据 Google Projec++t Zero 团队的分析，2021 年有 67% 的零日漏洞是内存安全漏洞。

2、矛头直指 C++和 C

虽然引发内存安全漏洞的原因有很多，但是在 CISA 等组织看来，内存安全漏洞需要用更好的代码来消除。

这一点正如美国国家安全局先前在《软件内存安全网络安全信息表》和其他出版物中指出的，最有希望的缓解措施是软件制造商使用内存安全程序设计语言，因为它是一种不容易受到内存安全漏洞影响的编码语言。

然而，最常见的 C 和 C++ 是内存不安全的编程语言。

CISA 表示，整个技术领域的互联网应用程序和设备都在使用这种内存不安全的编程语言，这种普遍性意味着目前在最关键的计算功能中存在着重大风险。

此前，C++ 的创建者 Bjarne Stroustrup 为该语言辩护，认为只要有适当的工具，符合 ISO 的 C++ 就可以提供类型和内存安全性。

不过，这一点观点并没有获得业界的普遍认可。甚至此前微软云开发推广部的 Ryan Levick 直言道，「无论软件公司在工具和人员的培训上投入多少精力也不能解决问题，因为 C++ 本质上就不是安全的语言。我们使用的语言由于年代久远、来自不同时代，无法为我们提供保护，让我们免受此类漏洞攻击。C++ 不是一种内存安全的语言，相信这一点无人有异议。」

3、“软硬”皆施，目标：消灭内存安全漏洞

事实上，针对这些频发的内存安全漏洞，各家科技公司也不是没有想过解决办法，根据 CISA 等机构在指南报告中收集的资料显示，互联网公司们不仅想过了软件解决办法，甚至也在着手开发新硬件。

软件解决之道

为了减轻 C 和 C++ 中内存不安全代码的危险，许多软件制造商投资于开发人员的培训计划，教会他们如何正确使用 C 和 C++。

很多科技公司也引入了代码覆盖测试、安全编码准则、Fuzzing 测试软件，以及开发者使用了静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）工具来查找各种软件的内存安全漏洞。

此外，C++ 社区一直在考虑如何在向后兼容性、内存安全默认值和基础语言的其他优先事项之间取得平衡。

详细来看，为了降低 C 和 C++ 在现有代码库和产品中的脆弱性，譬如：

苹果公司修改了用于构建 iBoot 引导载入程序的 C 编译器工具链，以减少内存和类型安全问题。虽然有外部分析表明，这可能会带来非同小可的性能和内存使用成本，但苹果还是这么做了。
微软早些年还开源了一个更安全的 C 语言版本——Checked C，在 C 语言中增加了静态和动态检查，以检测或防止常见的编程错误，如缓冲区侵占、内存访问越界、不正确的类型转换等。
Google 还打造了一款 C++ 的继任者——Carbon，针对现有代码的 C++ 内存安全采取了改进措施。

不过，CISA 表示，即使开发者进行了安全培训（以及持续努力强化 C/C++ 代码），但他们仍然会犯错误，导致内存安全漏洞几乎不可避免地仍然会发生。

硬件巨头也加入

除了从软件层面入手之外，很多硬件巨头也正在积极开发并使用硬件来支持内存保护。

其中，硬件增强型 RISC 指令的能力(Capability Hardware Enhanced RISC Instructions，简称 CHERI)项目是美国 SRI International 和剑桥大学的联合研究项目，为现有的芯片架构增加了新的功能。英国政府的数字安全设计（DSBD）计划汇集了 7000 万英镑的政府资金和 1.17 亿英镑的工业联合投资开发技术。

与此同时，在 2022 年，Arm 公司探讨了其实验性 Morello Program 及 CHERI 架构实现原理，希望借此解决系统攻击中常被利用的一系列内存访问漏洞。后来，微软也参与了 CHERI 研发的相关工作。现在他们还有一个开发人员社区，正在构建工具和库，以使该技术得到广泛应用。

虽然硬件中的内存保护还没有得到广泛应用，但一些行业观察人士认为，在许多迁移到 MSL 需要较长时间的部署场景中，内存保护将非常有帮助。在这种情况下，硬件刷新周期可能会很短，足以为客户提供重要的内存保护，直到其他保护可用。这些硬件保护的实验正在进行中，包括测试这些新设计的实际性能影响和内存消耗特性的工作。在某些情况下，如果软件能够最佳地使用硬件保护，那么硬件保护就有可能提高性能。

综合以上也不难看出，虽然一直以来软硬件制造商花费大量资源，试图通过各种方法（包括分析、打补丁、发布新代码和投资于开发人员培训计划）降低漏洞的普遍性和影响，但这些漏洞依然存在。

这也是 CISA 等机构为什么会想到发布该指南的原因。在 CISA 看来，内存安全编程语言（Memory Safe Programming Languages，MSLs）可以消除内存安全漏洞。因此，向 MSL 过渡可能会大大减少对旨在减少这些脆弱性或尽量减少其影响的活动的投资需求。此外，将不安全的代码库迁移到 MSL 的投资将以更安全的产品的形式支付一些过渡到 MSL 的前期成本，从而获得长期的红利。

4、内存安全编程语言有哪些？

在这份指南中，CISA 发布了一份安全的内存语言列表，包含了 C#、Go、Java、Python、Rust 和 Swift：

其中 CISA 花费了不小的篇幅介绍了时下在安全维度颇受欢迎的 Rust 语言，其表示 Rust 是一种编译语言，侧重于性能、类型安全和并发性。它有一个所有权模型，旨在确保每一个值都有一个对应的变量作为它的所有者。Rust 还有一个名为“借用检查器”的功能，旨在确保内存安全并防止并发数据竞争。虽然借用检查器系统并不完美，但它在解决编译时的内存安全问题方面发挥了很大作用。

Rust 在编译时强制执行正确性，以防止运行时出现内存安全和并发问题。举例来说，数据竞争是一类出了名难以追踪的软件错误。“有了 Rust，你就可以静态验证是否存在数据竞争。这意味着你可以避免棘手的错误，只要不让它们进入你的代码就可以了。编译器不会让你这么做的。”

时下，Rust 已经得到了包括 Linux 内核、Android 和 Windows 在内的几项备受瞩目的技术的高度关注。它还被用于 Mozilla 等应用以及 Dropbox、亚马逊和 Facebook 等其他在线服务。

5、说得容易，弃用 C++/C 后迁移岂是一件小事？

虽然话虽如此，不得不面对现实的是，在很多企业看来，只要没有发生重大安全事故，修修补补的 C、C++ 程序只要还能用，就继续使用。因为过渡到 MSL 需要管理层经过多年的仔细规划，也需要钱以及时间成本的支持。

基于此，CISA 表示，在 MSL 中重写现有代码可能是一个巨大的挑战，特别是如果代码已经运行良好，而组织还不具备所选 MSL 的专业知识。考虑从风险较低的新的、更小的项目开始，让团队有时间试验新的工具和流程。与此同时，其也分享了关于迁移的路线图建议：

1. 定义阶段，包括日期和结果。与所有软件开发工作一样，开发团队可以将较大的工作分解为具有明确结果的较小项目，以度量最新进展。具体包括 MSL 评估、测试在 MSL 中编写新组建的试点项目、找到最危险的内存不安全代码、重构内存不安全代码。
2. 确定新系统完全使用 MSL 的时间。此后，公司将会仅在 MSL 中编写新代码。
3. 内部开发者和培训和整合计划。没有 MSL 过渡是免费的，制造商需要留出时间让开发人员精通用所选语言编写软件、调试、工具、将 MSL 集成到生产环境中、全面的质量控制流程。
4. 外部依赖计划。路线图应该记录处理对用C和C++编写的库的依赖关系的计划。
5. 透明度计划。通过定期 (例如，每季度或每半年)更新来保持上述信息的最新性，将进一步建立组织正在认真对待内存安全漏洞的信心。
6. CVE 支持计划。行业需要详细和正确的公开数据，以了解给客户带来风险的漏洞类别。

由此，CISA 认为，这样做可以让用户知道制造商正在掌控安全结果，采用极高的透明度并采用自上而下的方法。除了 CISA 发布指南外，非营利性互联网安全研究小组联合创始人兼执行董事 Josh Aas 早些时候也向正在考虑向内存安全代码过渡的软件开发人员和开源维护人员提出了一些建议：