作者 | John Viega

译者 | 王强

策划 | Tina

本文作者 John Viega 拥有 25 年安全和开发经验，喜欢研究编译器，是 AES-GCM 加密算法的联合作者，曾是 McAfee 首席安全架构师、SaaS 业务部门的 CTO。并在纽约大学担任兼职教授至今。撰写了多本关于安全的书籍，包括《安全神话》、《构建安全软件》和《使用 OpenSSL 进行网络安全》等。是 IEEE 安全与隐私杂志的前主编。

他的这篇文章围绕行业长期存在的，关于 C/C++ 安全性不足及其应该被 Rust 等语言替代的话题展开了讨论，并发表了一些独特而有价值的观点。原文内容较长，译文删减了一部分不重要的内容以方便阅读。

前不久我又看到了一篇非常轻视内存安全性，觉得这方面没什么必要做改变的文章，然后我又看到一些安全专家对这篇文章回应说，想要保障安全、负起责任就得尽快放弃 C 和 C++ 才行。这篇文章就是我对这个话题的分析，我会尽可能覆盖所有方面，尽量让行业内的读者都能理解我的意思。

太长不看版本

1. 安全问题确实比很多人想的要严重得多，很多人应该立刻拒绝在新项目中使用 C/C++ ，理由也不仅是安全性考虑。但是！
2. 让我们的应用程序摆脱已有的所有 C 代码的成本和风险远高于许多人的想象；某些关键软件的替代品需要十年或更久才能成为主流，而且新软件的整体效益并不明显。
3. 安全性这个领域有许多隐藏的复杂性，所以“Rust 比 C 更安全”这句话可能是正确的，但因为那些复杂性，实际情况没那么简单。
4. 选择编程语言这种事情看似简单，经济层面实际上非常复杂。安全性不是唯一的非功能性考虑因素，而且无论你做什么，总会在某个地方存在内存不安全的代码（只要底层架构本身是不安全的），而且试图快速摆脱 C 代码会带来许多负面后果。
5. 系统语言被过度使用了；C vs Rust 的二选一其实是伪命题，因为像 Go 这样的编译语言在经济上往往是一个更好的全方位答案。特别是 Go 有足够好的性能，足以满足绝大多数用例，可以是安全的，并且可以很好地访问底层系统 API。 一些安全人员已经怒气冲冲了

我曾看到一位安全人员和业务部门争吵不休，于是我问他：

如果你认为安全是首要问题，那你为什么还要使用电脑？

人们每天都愿意承担风险。我们知道，只要我们外出，就有可能感染某种病毒。我们知道，只要我们上车，就有可能发生事故并丧命。

但众所周知，我们倾向于大大高估或低估自己的风险水平。

一般来说，安全行业可能认为普通人大大低估了风险。过去这个观点可能是正确的，但现在的世界已经不同了。曾几何时，大多数行业都大大低估了风险，网络连接可能被轻易篡改、代码可能被轻易攻破，没有例行补丁，也没有广泛的隔离或其他有效的权限机制。

但由于整个安全行业的辛勤工作，其他科技界从业人员最终承认他们错了。安全行业产生了巨大的影响力，从硬件架构到网络协议，再到编程语言设计都开始重视安全性。这条路走下来并不轻松，因为我们常常无法真正理解来自其他领域的专业观点。

如果我们能牢记这一点，行业就能取得更快的进步，获得更好的信誉。我们需要这样做，因为正如我们所看到的，要做的事情还有很多，而且还有很多重要的变化根本无法快速实现。

内存安全问题有多严重？

内存安全往往被认为是最严重的漏洞类别，因为这个层面的漏洞经常可以获得最高权限。漏洞经常可以被远程利用，有时甚至不需要任何身份验证。

但有观点认为内存安全漏洞数量众多，老练的攻击者很容易找到并利用它们，这种说法是错误的。

世纪初的时候情况的确是那样，但现在不一样了。从安全角度来看，内存不安全代码的影响肯定还是非常大，但还没有高到你要顶着经济压力为它换成内存安全语言的程度。

风险状况已经变了

我坚决承认相比 C/C++，其他语言本质上更安全；我只是在质疑“它们的安全性到底强多少？尤其考虑到我们已有的很多安全措施时。”

世界发生了许多变化，直接影响了风险水平（双向），包括：

1. 我们使用的硬件架构和操作系统都很好地帮助我们阻止了漏洞利用行为，同时又不牺牲太多性能。
2. C++ 专心围绕其标准库打造用户界面，试图确保普通 C++ 用户不太可能使用内存安全可能有问题的 API。另一方面，虽然 C 已经发展成为一种语言，但在这方面却更加保守。
3. 全面披露运动发生了，漏洞研究成为一个职业领域，结果最常见的 C 组件受到了相当多的审查，大大提高了 C 程序员对这类问题的认知。
4. 学术界不再教授 C++，转向 Java，然后是 Python。
5. 越来越多适合做系统语言的新语言出现了，其中较为关注内存安全的 Rust 最引人注目，还有 Zig、Nim 和其他几种语言也比较重视内存安全。
6. 向云端迁移的趋势以及现代技术栈的其他很多组成部分都是很好的抽象，但它们确实会增加攻击面。另一方面，它们也让分区隔离更加常见，从而减少了攻击影响。由于我们不再将那么多可逆二进制代码交到人们手中，专有代码往往会因为对外部没那么透明而获得更好的安全性（尽管容错设计确实经常让攻击者可以根据需要自动执行尽可能多的“攻击”）。

考虑上述情况：

1. C 和 C++ 代码中的许多内存问题被报告为可利用的，即使在实践中确实存在相关漏洞无法被利用的情况。很久以前，如果我看到一个明显的内存错误，那么它不仅很有可能被利用，而且我还可以很容易地构建一个有效的漏洞。我同意，对于我们这个行业来说，最好只是假设我们发现的任何内存问题都是可以利用的。然而，想要有效利用漏洞变得非常困难，并且已经从一种轻松获得的技能变成了非常罕见的技能。
2. 漏洞研究领域的经济学往往会扭曲风险认知。这是因为此类错误在经济层面是最有价值的，但也意味着对比不同语言的 CVE 可能没什么意义。此外，有价值的漏洞要么出现在不太可能被利用的地方，要么会进入“负责任的披露”周期，被修补从而消除风险。
3. 有时，人们之所以写 C 代码是有自己理由的。理解这些理由很重要。很少有新手觉得自己必须学 C 才能成为出色的程序员，但在嵌入式系统等场合，C 往往是更为实用的选择。

为什么对比不同语言的 CVE 数量容易误导人呢？举个例子——Linux 内核最近正式获得了为自己的代码库发布 CVE 的能力。但在他们看来，任何错误都可能带来他们不了解的安全隐患，因此 Linux 内核中发现的每一个错误现在都有自己的 CVE，尽管它们大多不是可利用的内存问题。

漏洞的利用可能性降低了

一方面，找到好的漏洞变得越来越难，这一事实并不重要，因为如果你不再用 C，这类问题就不再是问题了。

另一方面，漏洞研究人员比从前更努力，找到的漏洞却少很多，这表明实际的风险比以前更低了（尤其是在有良好的补偿控制措施的情况下）。如今，我倾向于认为许多 C 程序中存在问题的几率很高，但如果你有正确的设计，并花钱请合适的人来审查你的代码，那么找到下一个错误的经济成本就足够高了。

我刚开始进入这个领域时，工作往往很简单。如果你能找到一个数组形式的局部变量，那么你很可能可以诱使程序在数组之外写入。而且内存布局很容易预测，因此那时候我们很容易利用这种情况。

具体来说，局部变量经常保存在程序栈中。当你进入一个函数时，数据会被推送到堆栈上，你退出时，数据会从堆栈中弹出。这与函数调用后仍存在的长期内存分配（堆存储）是不一样的。

例如，过去我们经常看到这样的代码：

对外行来说上述代码可能看起来没什么问题。它创建一个数组，该数组初始化为零，其大小为操作系统支持的路径的最大大小。然后，它将某个 base_path 名复制到该数组中，最后将文件名附加到该数组的末尾。但即使在今天的系统上，如果攻击者可以控制这个函数或 base_path 的输入，也很容易让程序崩溃。

部分原因是 C 不跟踪内容的长度。在 C 中，strcpy 逐字节复制，直到遇到值为 0 的字节（所谓的 NULLbyte）。类似地，strcat 的工作方式是向前扫描到 full_path 中的第一个空字节，并从 filename 中复制，直到找到 NULL。在任何情况下，这两个函数都不会根据 fullpath 的长度来检查它们正在做什么。因此，如果你可以传入超过 PATH_MAX 减去 len(base_path) 个字符，你就能写入超出缓冲区末尾的数据。

过去，程序栈将自己的运行时数据与用户的数据混合在一起，这就是传统的栈溢出如此容易实现的原因所在。