这是一个创建于 46 天前的主题，其中的信息可能已经有所发展或是发生改变。
机翻 https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html
从设计上安全：Google 对内存安全的看法
Alex Rebert ，软件工程师 Christoph Kern ，Security Foundations 首席工程师
谷歌的零项目报告称，内存安全漏洞（由与程序访问内存方式相关的微妙编码错误引起的安全缺陷）一直是“过去几十年来攻击软件的标准，并且仍然是攻击者成功的方式”。他们的分析显示，在野外检测到的 0day 漏洞中，三分之二都利用了内存损坏漏洞。尽管投入了大量资金来改进内存不安全语言，但这些漏洞仍然是最常被利用的漏洞类别的首位。
在这篇文章中，我们在一份综合白皮书中分享了我们对内存安全的看法。本文深入研究了数据、解决内存不安全的挑战，并讨论了实现内存安全的可能方法及其权衡。我们还将强调我们对实施白皮书中概述的几个解决方案的承诺，最近向 Rust 基金会拨款 1,000,000 美元，从而推动强大的内存安全生态系统的发展。
为什么我们现在发布这个
2022 年是内存安全漏洞出现 50 周年。此后，内存安全风险变得更加明显。与其他公司一样，谷歌的内部漏洞数据和研究表明内存安全漏洞很普遍，并且是内存不安全代码库中漏洞的主要原因之一。这些漏洞危及最终用户、我们的行业以及更广泛的社会。我们很高兴看到各国政府也认真对待这个问题，就像美国国家网络主任办公室上周发表的一篇有关该主题的论文一样。
通过分享我们的见解和经验，我们希望激励更广泛的社区和行业采用内存安全的实践和技术，最终使技术更安全。
我们的观点
在谷歌，我们拥有数十年大规模解决曾经与内存安全问题同样普遍的漏洞的经验。我们的方法，我们称之为“安全编码”，将容易出现漏洞的编码构造本身视为危险（即，独立于它们可能导致的漏洞，并且除了它们可能导致的漏洞之外），并以确保开发人员在开发过程中不会遇到此类危险为中心。定期编码练习。
基于这一经验，我们期望只有通过以全面采用具有严格内存安全保证的语言为中心的安全设计方法才能实现高保证的内存安全。因此，我们正在考虑逐步过渡到 Java 、Go 和 Rust 等内存安全语言。
在过去的几十年里，除了大型 Java 和 Go 内存安全代码库之外，Google 还开发并积累了数亿行 C++ 代码，这些代码正在积极使用和持续开发中。这个非常庞大的现有代码库给向内存安全的过渡带来了重大挑战：
我们看不到将 C++ 演进为具有严格内存安全保证（包括时间安全性）的语言的现实路径。
将所有现有 C++ 代码大规模重写为不同的内存安全语言似乎非常困难，并且可能仍然不切实际。
我们认为，在可行的范围内，通过现有 C++ 代码的安全改进来补充新代码（尤其是有风险的组件）向内存安全语言的过渡非常重要。我们相信，通过逐步过渡到部分内存安全的 C++ 语言子集，并在可用时通过硬件安全功能进行增强，可以实现重大改进。例如，请参阅我们在 GCP 网络堆栈中改进空间安全性的工作。
我们对内存安全语言的投资
我们正在积极投资白皮书中概述的许多解决方案以及对美国联邦政府关于开源软件安全的 RFI 的回应。
Android 在过去几年中用 Rust 编写了多个组件，带来了引人注目的安全改进。在 Android 的超宽带（ UWB ）模块中，这提高了模块的安全性，同时还减少了内存使用和过程间调用。
Chrome 已经开始在 Rust 中提供一些功能；在一种情况下，Chrome 能够通过采用用 Rust 编写的新内存安全库将其 QR 代码生成器移出沙箱，从而实现更好的安全性和更好的性能。
Google 最近宣布向 Rust 基金会拨款 1,000,000 美元，以增强与 C++ 代码的互操作性。这将有助于在现有内存不安全代码库中逐步采用 Rust ，这对于以内存安全语言进行更多新开发至关重要。与此相关，我们还致力于解决在同一二进制文件中混合 Rust 和 C++ 时可能发生的跨语言攻击。
Google 正在通过 ISRG Prossimo 和 OpenSSF 的 Alpha-Omega 项目投资构建内存安全的开源生态系统。早在 2021 年，我们就资助了将 Rust 引入 Linux 内核的工作，现在使我们能够编写内存安全的驱动程序。这笔资金还将用于以内存安全语言提供关键开源库的替代方案或升级，例如提供内存安全 TLS 实现。
我们知道内存安全语言不会解决所有安全错误，但正如我们通过工具消除 XSS 攻击的努力所表明的那样，消除大量漏洞既可以直接使软件消费者受益，也可以让我们将重点转移到解决其他类别的安全问题上漏洞。
要访问完整的白皮书并详细了解 Google 对内存安全的看法，请访问 https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/
从设计上安全：Google 对内存安全的看法
Alex Rebert ，软件工程师 Christoph Kern ，Security Foundations 首席工程师
谷歌的零项目报告称，内存安全漏洞（由与程序访问内存方式相关的微妙编码错误引起的安全缺陷）一直是“过去几十年来攻击软件的标准，并且仍然是攻击者成功的方式”。他们的分析显示，在野外检测到的 0day 漏洞中，三分之二都利用了内存损坏漏洞。尽管投入了大量资金来改进内存不安全语言，但这些漏洞仍然是最常被利用的漏洞类别的首位。
在这篇文章中，我们在一份综合白皮书中分享了我们对内存安全的看法。本文深入研究了数据、解决内存不安全的挑战，并讨论了实现内存安全的可能方法及其权衡。我们还将强调我们对实施白皮书中概述的几个解决方案的承诺，最近向 Rust 基金会拨款 1,000,000 美元，从而推动强大的内存安全生态系统的发展。
为什么我们现在发布这个
2022 年是内存安全漏洞出现 50 周年。此后，内存安全风险变得更加明显。与其他公司一样，谷歌的内部漏洞数据和研究表明内存安全漏洞很普遍，并且是内存不安全代码库中漏洞的主要原因之一。这些漏洞危及最终用户、我们的行业以及更广泛的社会。我们很高兴看到各国政府也认真对待这个问题，就像美国国家网络主任办公室上周发表的一篇有关该主题的论文一样。
通过分享我们的见解和经验，我们希望激励更广泛的社区和行业采用内存安全的实践和技术，最终使技术更安全。
我们的观点
在谷歌，我们拥有数十年大规模解决曾经与内存安全问题同样普遍的漏洞的经验。我们的方法，我们称之为“安全编码”，将容易出现漏洞的编码构造本身视为危险（即，独立于它们可能导致的漏洞，并且除了它们可能导致的漏洞之外），并以确保开发人员在开发过程中不会遇到此类危险为中心。定期编码练习。
基于这一经验，我们期望只有通过以全面采用具有严格内存安全保证的语言为中心的安全设计方法才能实现高保证的内存安全。因此，我们正在考虑逐步过渡到 Java 、Go 和 Rust 等内存安全语言。
在过去的几十年里，除了大型 Java 和 Go 内存安全代码库之外，Google 还开发并积累了数亿行 C++ 代码，这些代码正在积极使用和持续开发中。这个非常庞大的现有代码库给向内存安全的过渡带来了重大挑战：
我们看不到将 C++ 演进为具有严格内存安全保证（包括时间安全性）的语言的现实路径。
将所有现有 C++ 代码大规模重写为不同的内存安全语言似乎非常困难，并且可能仍然不切实际。
我们认为，在可行的范围内，通过现有 C++ 代码的安全改进来补充新代码（尤其是有风险的组件）向内存安全语言的过渡非常重要。我们相信，通过逐步过渡到部分内存安全的 C++ 语言子集，并在可用时通过硬件安全功能进行增强，可以实现重大改进。例如，请参阅我们在 GCP 网络堆栈中改进空间安全性的工作。
我们对内存安全语言的投资
我们正在积极投资白皮书中概述的许多解决方案以及对美国联邦政府关于开源软件安全的 RFI 的回应。
Android 在过去几年中用 Rust 编写了多个组件，带来了引人注目的安全改进。在 Android 的超宽带（ UWB ）模块中，这提高了模块的安全性，同时还减少了内存使用和过程间调用。
Chrome 已经开始在 Rust 中提供一些功能；在一种情况下，Chrome 能够通过采用用 Rust 编写的新内存安全库将其 QR 代码生成器移出沙箱，从而实现更好的安全性和更好的性能。
Google 最近宣布向 Rust 基金会拨款 1,000,000 美元，以增强与 C++ 代码的互操作性。这将有助于在现有内存不安全代码库中逐步采用 Rust ，这对于以内存安全语言进行更多新开发至关重要。与此相关，我们还致力于解决在同一二进制文件中混合 Rust 和 C++ 时可能发生的跨语言攻击。
Google 正在通过 ISRG Prossimo 和 OpenSSF 的 Alpha-Omega 项目投资构建内存安全的开源生态系统。早在 2021 年，我们就资助了将 Rust 引入 Linux 内核的工作，现在使我们能够编写内存安全的驱动程序。这笔资金还将用于以内存安全语言提供关键开源库的替代方案或升级，例如提供内存安全 TLS 实现。
我们知道内存安全语言不会解决所有安全错误，但正如我们通过工具消除 XSS 攻击的努力所表明的那样，消除大量漏洞既可以直接使软件消费者受益，也可以让我们将重点转移到解决其他类别的安全问题上漏洞。
要访问完整的白皮书并详细了解 Google 对内存安全的看法，请访问 https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/
4 条回复 • 2024-03-12 12:18:03 +08:00
 |
1
yanaraika 46 天前
以后有明确 boundary 的、安全要求高的项目会逐渐过渡到 rust
但作为同样在维护超大 C++业务代码库（ 20K 文件，6M 行源代码）的情况，个人看不到“在现有内存不安全代码库中逐步采用 Rust”的可能性。Chrome 、Android 可以替换一部分有明确 boundary 的组件成为 Rust ，而业务代码库常常没有明确的界限（甚至 linking dependency 都不是一个 DAG ，而是一个组的一百多个文件--whole-archive 交织在一起）。之前内部曾经尝试过各种 binding 方案，但全都失败了。 |
 |
2
andytao 46 天前
|
 |
3
agagega 46 天前 via iPhone
几大 C++编译器其实一直有把还没进入标准的特性先实现出来看反响的传统，但给 C++加上完整的内存安全性这个改动太大（比如 Herb Sutter 的 Cpp2 ），单靠几个生命期标记还不行，所以没太大动作。
|
1
Select Language