编程语言数百种，哪种才是最安全的？
作者
微软安全响应中心
译者
弯月，责编
屠敏
以下为译文：
此前我们讨论过主动解决内存安全问题的必要性。显然仅通过工具和指导无法阻止这类漏洞。十多年来，内存安全问题与CVE（常见漏洞披露）的比例非常接近。我们认为，使用内存安全语言可以通过工具和培训无法实现的方式来缓解这种情况。
在这篇文章中，我们将探讨一些真实的微软产品漏洞示例（经过测试和静态分析），这些漏洞可以通过使用内存安全语言来防止。
内存安全
内存安全是编程语言的一种特性，在拥有内存安全的编程语言中，所有的内存访问都有明确的定义。目前使用的大多数编程语言都通过某种形式的垃圾回收实现了内存安全。然而，无法承受垃圾收集器那般繁重的运行时的系统级语言（即用于构建其他软件所依赖的底层系统的语言，比如OS内核、网络栈等）通常都不是内存安全的。
微软修复并指定了CVE的安全漏洞中，大约70%的根本原因都是内存安全问题。尽管我们采取了缓解措施，包括严格的代码审查、培训、静态分析等等。
微软70%的漏洞仍然是内存安全问题
虽然许多有经验的程序员可以编写正确的系统级代码，但很明显无论采用何种缓解措施，使用传统的系统级编程语言编写内存安全的代码几乎是不可能的。
下面，让我们看一些现实生活中由于使用没有内存安全保证的语言而引发的安全漏洞的例子。
空间内存安全
空间内存安全指的是确保所有内存访问都位于被访问类型的边界内。为此需要代码来跟踪这些大小，并根据这些大小正确检查所有的内存操作。
控制流的极端情况下可能漏掉检查，或者由于没有考虑到整数符号、整数提升或整数溢出的复杂性而错误地实现检查。让我们看看如下MicrosoftEdge的这个例子，由AlexandruPitis发现（CVE--）：
[0]处的检查是正确的。但是，[1]可以修改字符串的大小，使得获取的偏移量失效。这就导致[2]处调用复制函数时使用了与预期不同的偏移量，导致了越界写入。
该漏洞的修复很简单：将“偏移检查”移动到距离使用时更近的地方。问题在于，复杂的代码库中很容易出现这个错误，而且简单地重构代码也可能会再次引发这个漏洞。现代C++提供了span来强制执行数组访问的边界检查。然而，不幸的是这不是默认值，所以是否使用span完全依赖于开发人员。因此在实践中很难强制使用这种结构。
如果编程语言能够自动跟踪和验证大小，那么程序员就不必再担心正确实现这些检查，而我们也可以确定我们的代码中不存在这些问题。
时间内存安全
时间内存安全指的是确保指针在解引用时仍然指向有效的内存。
一个常见的模式就是释放后使用，该漏洞的触发方法是，首先对某个内存取引用后保存到局部指针中，然后执行一系列复杂的操作，这些操作可能会释放或移动该内存，导致局部指针中的引用过时，然后在引用失效后进行解引用。例如StevenHunter发现的Edge的源代码示例（CVE--）：
这个错误的原因是，太多的复杂API互相交互，程序员无法强制整个代码中的内存所有权。在[0]处，程序获取指向JavaScript对象拥有的对象指针。然后在[1]处，由于语言的复杂性，代码需要执行更多的JavaScript代码才能获取另一个变量。在[2]出，它会使用该缓冲区和宽度，使用该指针的内容来创建新的JavaScript对象。
问题在于：
程序同时使用了垃圾回收和手动内存管理。垃圾回收器会跟踪JavaScript对象，但它并不知道是否有指针指向对象的内部。由于VarToInt重入了JavaScript，JS程序可以修改状态，并清除在[1]处创建过别名的那个指针的所有权。这个漏洞与迭代器失效bug类似，当状态被修改时，所有指向JavaScript内部状态的指针都可能变成无效指针。但是在浏览器这样复杂的程序中，用静态方式来确保不发生该bug几乎不可能。该问题的根源在于给指向可修改状态的指针添加别名。C和C++没有相应的工具来防止这种错误。但是，我们建议始终使用“智能指针”来跟踪内存所有权。
数据竞争条件
当同一个进程中的两个或多个线程同时访问同一个内存地址，且至少有一个访问是写操作，而且线程没有使用任何明确的锁操作来控制对该内存的访问时，就会发生数据竞争。在多线程访问共享数据的情况下，保持空间和时间的内存安全变得更加困难，而且更易于出错。即使只在非常小的一段时间内共享没有同步的内存，也有可能被其他线程修改数据，而被修改的数据正是引用其他内存地址的数据。这就是检查时/使用时（TOCTOU）漏洞的原因之一，其会导致空间和时间内存安全漏洞。
JordanRabet在Blackhat上披露的VMSwitch漏洞演示了数据竞争可能造成的影响。这段代码在虚拟机给宿主发送特定消息时被调用。这意味着，它可以以并行方式调用，来处理其他控制消息和数据包。这样做是有问题的，因为控制消息的处理函数使用的信息在被修改时没有进行任何锁操作[0]。
下面这段代码被多个控制消息处理函数使用，从中可以看出被更新的信息被使用的过程：
由于未同步的访问，新的缓冲区可能被旧的opHostData-AllocatedRanges[1]的值使用，导致越界写操作[3]。
防止此类漏洞需要对多个线程访问的数据结构进行加锁操作，直到数据处理完成。但是，在C++中并没有容易的静态检查方法来强制这一点。
我们该怎么办
解决本文提出的几个问题需要几种不同的度量。C++中的“现代”结构（如spanT）至少可以防止某些类型的内存安全问题，而其他的现代C++特性（如智能指针）应当尽可能使用。但是，现代C++依然不是完全内存安全、完全没有数据竞争的语言。更糟糕的是，这些特性使用与否，完全依赖于程序员“做正确的事情”，在大型、模糊的代码库中几乎不可能强制这一点。C++也没有能够用安全的抽象来包裹不安全代码的工具，意味着尽管在局部可以强制正确的编程习惯，但用C或C++构建安全的组件将极其困难。
除此之外，软件还应当尽可能转移到完全内存安全的语言，如C#或F#等通过运行时检查和垃圾回收来保证内存安全的语言。毕竟，除非必要，否则不应当涉足复杂的内存管理。
如果出于速度、控制和可预测性等合理的理由而使用C++，那么可以考虑转移到内存安全的系统编程语言上。文章我们将介绍为什么我们认为Rust是目前最合适的编程语言，因为它能够以内存安全的方式编写系统级的程序。
原文：
