超越C

数十年来，C及其直接衍生语言一直是系统编程的首选语言。20世纪70年代初，C语言问世，相较于汇编语言实现了重要突破。50年后的今天，我们可以做得更好。

1970年，计算机安全尚未引起大多数人的关注，此后多年也是如此。直到1988年，互联网上才出现首个重大安全漏洞。它被称为“互联网蠕虫”，利用了缓冲区溢出，即对内存中的数组进行越界索引。

在包括C++在内的C语言家族中，数组不会进行边界检查。程序员需要确保正确访问数组。因此，缓冲区溢出错误很常见。更糟的是，攻击者很容易故意造成缓冲区溢出，从而访问本不应访问的内存。

缓冲区溢出只是内存不安全的一个例子。其他相关示例包括指针运算和悬空指针（也称为释放后使用漏洞）。如今，许多编程语言采用各种技术，确保用这些语言编写的任何程序都不会出现内存安全问题。C语言家族并不提供此类保证；内存安全从来都不是这些语言的设计目标。

约70%的安全漏洞源于违反内存安全原则。大量数据充分支持这一说法。内存安全问题在以下方面所占比例为：

• 已披露且在实际环境中检测到的已利用漏洞中，67%与内存安全有关（根据Google Project Zero 2021的估算）。
• 90%的Android漏洞（据Google称）。由于采用了Rust，这一比例近期有所下降，但89%的可远程利用漏洞仍与内存安全有关。
• Microsoft漏洞中有70%属于此类（数据来源：Microsoft）。
• Apple近期修复的大多数漏洞（涉及Catalina、Big Sur、Monterey、Safari、iOS、tvOS和watchOS）。

2022年7月，Chrome 103.0.5060.134中修复的漏洞有5/6属于内存安全问题。显然，消除内存安全缺陷将大有帮助。多年来，业界一直知道如何做到这一点：使用内存安全的编程语言。过去，问题始终在于由此带来的性能成本。鉴于内存安全的重要性，人们一直在探索新策略，以避免传统开销并实现内存安全。如今，我们已经知道如何以极低甚至为零的运行时成本消除内存安全错误。Rust等语言通过创新的类型系统设计，无需成本高昂的运行时支持即可保证内存安全。

由此可以得出一个不可回避的结论：停止使用C/C++（更广泛地说，停止使用内存不安全的语言）编写新的系统代码。

这并不是在呼吁大规模、不加区分地重写现有代码。替换现有软件成本高昂，也并非没有风险。然而，业界必须停止向现有代码库添加更多内存不安全代码，以免问题进一步恶化。对于现有代码，应优先重写最敏感的组件，例如负责验证或处理不可信用户输入的组件、在特权上下文中运行的组件、在沙箱外运行的组件等。

这一观点虽已得到广泛认同，但仍存在一些争议。以下是支持维持现状的一些常见论点，以及我们对此的回应。

• 错误并非编程语言所特有。
  • 大多数漏洞都源于内存安全缺陷。Rust等内存安全语言不会出现内存安全缺陷。因此，使用内存安全语言可以从源头上避免产生大多数漏洞。
• 代码审查会发现缺陷。
  • 研究表明，虽然代码审查可能有所帮助，但往往会漏掉许多问题，当然也不可能发现所有问题。
• 不安全的模块会让这一切失去意义。
  • 不安全代码会被明确限定在非常小的代码段内，因此可以集中资源对其进行验证。
• 内存安全语言的实现可能存在缺陷。
  • 确实如此，但发生这种情况的概率要低得多。编译器相对较小，并经过严格测试。此外，修复编译器后，所有使用该编译器编译的程序都会自动得到修复，而修复单个程序中的错误只能解决该程序的问题。
• 只有新手或能力不足的程序员才会犯这些错误。
  • 恰恰相反，上述数据来自Chrome浏览器以及Windows和MacOS操作系统等大型系统项目。这些项目汇聚了业内能力出众、经验丰富的开发人员，但仍然存在内存安全问题。
• 遵循良好实践可以避免这些问题。
  • 请参见上文。上述团队遵循非常严格的实践规范，并使用先进的可用工具。
• 重写所有代码并不现实。
  • 没有人主张彻底重写所有代码。建议采用一种更切实可行的方法：重点关注关键要素（高权限、攻击面大、对安全保障至关重要），并使用内存安全语言编写新代码。
• 性能不足。
  • Rust的性能与C/C++大致相当。细微的性能差异不足以成为承担安全风险的理由。在某些情况下，Rust程序的运行速度还可能更快。
• 像Rust这样具备内存安全性的系统编程语言还太新。
  • Rust正逐步进入Linux内核。
  • Firefox等Web浏览器的大量组件均使用Rust编写。
  • Google已向Android添加了大量Rust代码，且未发现任何漏洞。
• 还有其他解决方案，例如静态分析、模糊测试和沙箱技术。
  • 安全需要采用分层方法。
  • 沙箱技术存在局限性。
  • 即使采用成熟的现代C++实践，也无法遏制漏洞激增的势头。

有关上述要点的详细讨论，请参阅《量化内存不安全问题及其应对措施》。

尽管存在反对意见，推动必要变革的势头仍在增强。例如，开源软件安全基金会（由Linux基金会支持）正获得大量投资。美国参议院的报告以及美国国家安全局都曾探讨内存安全问题。《消费者报告》也提出了一系列面向企业和州政府机构的建议，以确定可能加速这一进程的各种激励措施。

总结如下：

过去50年来，计算技术对社会的重要性大幅提升。近几十年来，计算基础设施面临的威胁形势也发生了根本性变化。然而，我们用于构建计算系统的编程语言并未随之改变。缺乏内存安全是软件安全漏洞最主要的单一来源。这并非某类特定软件独有的问题：凡是使用内存不安全语言的地方，内存安全问题都十分普遍。从数量上看，其他任何类别的漏洞都远不及此。

如今，我们已经具备解决这一日益严峻问题的手段，整个行业必须采取行动。所幸，越来越多的人开始认识到这一现状，但问题十分紧迫，刻不容缓。