C++ 的创造者呼吁帮助保护编程语言免受 “严重攻击

|

C++ 的创造者 Bjarne Stroustrup 呼吁 C++ 社区捍卫这种编程语言，近年来，网络安全机构和技术专家一直在回避这种语言的内存安全缺陷。

C 和 C++ 都是围绕手动内存管理而构建的，这可能导致内存安全错误，如越界读写，尽管这两种语言都可以编写并与工具和库相结合，以帮助最大限度地降低这种风险。这类错误一旦出现，就会成为大型代码库中的大多数漏洞。

过去三四年来，随着这些漏洞被高调利用并造成经济损失，业界和政府的网络安全专家一直在劝阻使用 C 和 C++，同时大力推广具有更好内存安全性的语言，如 Rust、Go、C#、Java、Swift、Python 和 JavaScript。

对此，C/C++ 社区提出了许多实现内存安全的建议，包括 TrapC、FilC、Mini-C 和 Safe C++ 等等。

但是，随着哥伦比亚大学计算机科学教授斯特劳斯特鲁普发出警报，问题显然不仅仅是进展缓慢，而是缺乏一个能与科技行业对 Rust 的崇拜相抗衡的公共叙事。

在2月7日支持其Profiles内存安全框架的 “致C++标准委员会的说明”（WG21）中，他写道：”这显然不是一份传统的技术说明，而是一份提出新语言或库特性的说明。它是对 C++ 受到前所未有的严重攻击的部分回应，是对紧急行动的呼吁。我认为 WG21 需要做一些有意义的事情，而且要让人们看到它在做。Profiles 就是一个可以做到这一点的框架。

他在说明中继续说：”正如我之前所说，这也是一个机会，因为类型安全和资源安全（包括内存安全）从一开始就是 C++ 的关键目标。

“我对此深有感触。请不要被我相对平静的语言所迷惑。

Stroustrup 并不以托瓦尔兹式的谩骂或夸张而闻名。他上一次使用如此强调的语言（据我们所知）还要追溯到 2018 年，当时他要求 C++ 社区放慢脚步，以更加协调的方式提出语言改进建议。“我们正走在一条可能毁掉 C++ 的道路上，“他当时警告说，”我们必须离开这条道路！”

2 月 13 日，Stroustrup 在以安全为重点的 SG23 邮件列表上发表了一条信息，针对 C++ 面临威胁的怀疑论，Stroustrup 引用了美国政府 CISA 去年 10 月发布的《产品安全不良实践报告》。

报告指出，到 2026 年 1 月 1 日，制造商应该为使用内存不安全语言的产品制定内存安全路线图，从而消除内存安全漏洞，或者采用内存安全的编程语言。Stroustrup 引用报告中的指导意见说：”我认为这是一个可信的威胁。

在撰写这篇报道时，斯特劳斯特鲁普正在国外旅行，他告诉《The Register》，他希望进一步阐述此事，但担心匆忙的回应可能会被误解或断章取义。但他同意将自己在邮件列表中的言论写入报道。

Stroustrup 非常清楚内存安全编程日益受到重视，他曾在 2022 年直接回应微软 Azure 首席技术官马克-鲁西诺维奇（Mark Russinovich）的呼吁：”停止用 C/C++ 启动任何新项目，在需要使用非[垃圾收集]语言的情况下使用 Rust。

斯特劳斯特鲁普撇开鲁西诺维奇的言论，认为他迷恋一种闪亮的新语言，他回应说：”在许多情况下，安全性显然至关重要，因此我多年来一直致力于提高 C++ 的安全性。

他呼吁采用一种渐进的方法–通过测试和工具对 C++ 代码进行现代化改造，使其更加安全–而不是一场将 C++ 扔出窗外的革命。

这也是谷歌所支持的立场，它承认传统的 C 和 C++ 将存在多年，需要加以管理。

但就在本周，“巧克力工厂 ”明确表示，相比 C/C++ 的现代化，它更关注内存安全的未来。

“我们呼吁进行根本性的转变：集体承诺最终消除这类（内存安全）漏洞，并以安全设计实践为基础–这不仅是为了我们自己，也是为了子孙后代。

鉴于 CISA 呼吁在 2026 年之前淘汰 C/C++，留给 C/C++ 社区做出回应的时间已经不多了。

负责 TrapC 项目的罗宾-罗（Robin Rowe）认为 Profiles 不会及时出现，也不认为 Profiles 是一个实用的解决方案。

“他对《The Register》说：”如果你对代码进行标记以执行Profile，C/C++语言的某些功能就会停止工作。“这就像Linux中的-Wall和-Wextra编译器标志，只不过它不是将警告升级为错误，而是关闭指针或数组。”

Rowe 解释说，C++ 程序员会用 Profile 标记他们的代码，然后重写由于 Profile 限制而导致错误的部分。

他说：“例如，对 C 数组进行迭代的 C for 循环必须替换为使用 std::vector 进行同样操作的 C++ for-each 循环。”他称，这是一种迫使 C++ 程序员使用最新的《C++ 核心指南》重写代码的制度。

Rowe 说：“没有人说过要指望 C++ Profiles 在 2026 年之前被 ISO C++ 委员会标准化，或者在编译器中实现。”他还怀疑 DARPA 的 TRACTOR 项目（用于 C 到 Rust 的自动转换）届时能否准备就绪。

罗在这场竞赛中占有一席之地–他最近向国际标准化组织C语言委员会介绍了他在TrapC编译器上的工作，他预计该编译器将于今年晚些时候完成，作为C编程语言的潜在扩展。2 月 27 日星期四，在奥地利格拉茨举行的 ISO C 委员会标准机构会议上，他回答了有关该项目的问题。

“他说：”TrapC Memory Safe Pointers（MSP）不会缓冲区超限，也不会隔行扫描。“当使用 TrapC 编译器编译 C 代码时，所有指针都会变成 MSP 并接受检查。

Rowe 认为，其他 C 和 C++ 内存安全方案并不全面。“可由程序员配置的 C/C++ 编程语言子集，无论是 C++ Profiles、C 扩展 N3211 还是其他，其脆弱性在于内存安全性无法保证在所有编译单元中保持一致，”他解释说。

“有了子集，就很容易在本应是内存安全的代码中创建一个不安全的漏洞，使内存使用不受检查。Rust 无法幸免，但也很脆弱。Rust 程序可能会使用 Rust 的’不安全’关键字打开一个漏洞，并广泛用于访问臭名昭著的不安全 C 指针”。

剑桥大学客座研究员、SCI 半导体公司系统架构总监 David Chisnall（该公司生产基于能力硬件增强 RISC 指令（CHERI）的内存安全硬件）在回应 Stroustrup 的 SG23 号召时，对内存安全的语言级解决方案表示怀疑。

“他写道：”现在很少有东西是用单一语言编写的，跨语言的内存安全性非常重要。他写道：”如果你用 Lua 脚本编写 Rust 内核，但 Lua 并不尊重 Rust 独特的所有权模型，那么就很难实现安全互操作。安全互操作的工具非常重要。

Chisnall 认为，让 C 和 C++ 更安全是比用 Rust 或其他内存安全语言重写代码更好的方法。

“他解释说：”从 C 到当前的 C++，再到具有更强安全性的 C++，这种渐进式迁移是一种很好的方法，因为你可以零敲碎打地进行迁移。

他解释说：”一次性重写数十亿行代码是个问题：即使最终结果是内存安全的，重写代码也会引入错误，而其中很多错误都是安全或保安方面的关键问题。将 C 语言迁移到安全的 C++ 方言，人们可以在数年时间内一点一点地完成，这对 C++ 来说将是一件好事。

谁将是这个故事的作者还有待观察。

也就是说，如果内存安全仍然是政府关心的问题的话。正如 Chisnall 所说：”美国新政府已经删除了白宫网站上的所有内容，并解雇了大部分从事内存安全工作的 CISA 人员……”

本文文字及图片出自 C++ creator calls for help to defend programming language from 'serious attacks'

你也许感兴趣的：

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注