美国国家安全局督促弃用 C/C++，使用更安全的 Rust、C# 等 _小知识

作者 | 苏宓
出品 | CSDN（ID：CSDNnews）
如果说此前 Kotlin、Dart、Julia、Carbon 等后起之秀向老牌编程语言发起挑战进攻都是小打小闹，那么这一次 C、C++ 这几种常青藤编程语言则是真实地陷入了尴尬的境地。
近日，美国国家安全局（NSA）发布了最新的指南，鼓励多个组织将编程语言从 C/C++ 转为使用内存安全的语言，如 C#、Rust、Go、JAVA、Ruby 和 Swift，主要原因是这样可以帮助软件开发者和使用者预防并缓解软件内存安全问题，这些问题占可利用漏洞的很大一部分。
安全的第一大“杀手”——内存漏洞
一直以来，内存安全的漏洞引起多个企业与开发者的警觉。
根据长期关注内存漏洞的开发者 @LazyFishBarrel 的统计，苹果公司的 IOS 和 macOS 系统中 60%-70% 的漏洞是内存安全漏洞。

文章插图
微软在 2019 年的一次会议上透露，从 2006 年到 2018 年，其发现的 70% 的漏洞都是因内存安全问题造成的。

文章插图
据 google 估计， Chrome 中存在了类似比例的内存安全漏洞，另外 90% 的 Android 系统漏洞也都是内存安全问题。
为此，NSA 认为，黑客极有可能会利用代码中管理不善的内存漏洞，而这种漏洞在程序员使用灵活性更高的编程语言时更容易出现。于是，其最新发布了《软件内存安全之网络安全信息指南》时，写道，「黑客可以利用这些漏洞进行远程代码执行或其他不利影响，这通常会危及设备，并且成为大规模网络入侵的第一步」，因此 NSA 建议各个组织尽可能使用内存安全语言，并通过代码强化防御（如编译器选项、工具选项和操作系统配置）来增强保护。
NSA 网络安全技术总监 Neal Ziring 表示，在开发消除此类漏洞的软件时，必须始终使用内存安全语言和其他保护措施。
C、C++ 成为重灾区
在 NSA 看来，我们常用的编程语言如 C 和 C++，在内存管理方面提供了很大的自由度和灵活性，但用这种语言开发的应用程序的安全性很大程度上需要依赖程序员的测试、检测环节。
不过，只要程序员自身稍微有些疏忽，简单的 Bug 也会带来严重的内存漏洞。
虽然当前行业中有很多软件分析工具能够检测到许多内存管理问题，操作环境选项也可以提供一些保护，但内存安全软件语言所提供的固有保护可以防止或减轻大多数内存管理问题。
针对这一问题，几年前，微软云开发推广部的 Ryan Levick 在分享微软为什么要从 C/C++ 转向 Rust 时，也曾直言，「无论软件公司在工具和人员的培训上投入多少精力也不能解决问题，因为 C++ 本质上就不是安全的语言」。他表示：“我们使用的语言由于年代久远、来自不同时代，无法为我们提供保护，让我们免受此类漏洞攻击。C++ 不是一种内存安全的语言，相信这一点无人有异议。”
近日来，微软 Azure CTO Mark Russinovich 也再次呼吁，「是时候停止使用 C/C++ 启动任何新项目」。
然而，众所周知，C 和 C++ 是编写核心系统软件的默认语言。这两门编程语言速度快，而且源代码可以直接汇编成机器语言。
虽然一边有很多企业高管呼吁不要用，但另一边也有很多人不信邪，不愿相信 C、C++ 语言的不足之处。
为此，有人称，“只要你不使用从 C 继承的任何功能，C++ 就是安全的”，亦或者“只要遵从现代 C++ 的类型和管用做法，就不会引发内存方面的漏洞” 。针对这一争论，科技圈中有开发者现身说法，根据自身在大型 C++ 项目上（遵从现代的惯用做法）的开发经验，发表了《现代 C++ 救不了程序员》一文，用实例证明 C++ 提供的类型完全不能阻止漏洞的泛滥。
另外，也有人提出质疑，“为什么非要弃用 C、C++ 呢，有什么理由不能在 C、C++ 编译器中强制执行内存安全吗？”
针对这一点，有开发者进行回应：
这在以前就已经尝试过了。
但挑战是双重的。首先，如果在编译器强制执行内存安全，范围也只能局限在编译器上。然而，真正的内存安全实际上是（至少）线程安全、空值安全和类型安全，以及大多数人所想的原始边界检查等各个方面。除非你打算进入托管语言领域（Managed Language）并引入 GC，否则你需要语言级别的结构来允许程序员在这些新的边界内有效工作。例如，在 Rust 中，这就是 "所有权 "系统。