先丢出美国国家安全局的一篇文章：NSA Releases Guidance on How to Protect Against Software Memory Safety Issues：
この記事は2つの記事から翻訳されています。1つ目は、米国国家安全保障局の“ソフトウェアメモリセキュリティ”ネットワークセキュリティ情報シートの解釈であり、2つ目は、メモリセキュリティとは何か、なぜ重要なのかを普及させることです。
メモリ攻撃を回避するため、NSAはRust、C#、Go、Java、Ruby、Swiftを推奨するが、CとC++は脇に置く
本文は翻译Google翻译加持から来ています。
著者：リアム·トゥング
NSAから開発者へ：CとC++からメモリセーフなプログラミング言語へのスイッチングについて考える
原文へのリンク：https//www.zdnet.com/article/nsa-to-developers-think-about-switching-from-c-and-cpp-to-a-memory-safe-programming-language/
多くの開発者にとって、これはC#、Go、Java、Ruby、Rust、Swiftへの移行を意味します。
米国国家安全保障局（NSA）は、リモートコード実行やその他のハッキングからコードを保護するために、C#、Go、Java、Ruby、Rust、Swiftなどのメモリ安全言語に移行するよう開発者に促しています。
上記の言語の中で、JavaはエンタープライズおよびAndroidアプリケーション開発で最も広く使用されている言語であり、SwiftはiOSアプリケーション開発のおかげでトップ10に入っています。システムプログラミングでは、CやC++の代替としてRustが注目されています。
“NSAは、可能な場合には、内蔵メモリ保護をほとんどまたはまったく提供しないプログラミング言語（C/C++など）から、メモリ安全言語への戦略的転換を検討するよう組織に助言しています。メモリセーフのいくつかの例には、C#、Go、Java、Ruby、Swiftがあります。”NSAは言った。
该间谍机构援引谷歌和微软最近的研究表明，他们 70% 的安全问题（分别在 Chrome和 Windows 中）与内存相关，其中许多是使用 C 和 C++ 的结果，它们更容易出现基于内存的漏洞.
另外： 网络安全、云和编码：为什么这三项技能将在 2023 年引领需求
美国国家安全局在“软件内存安全”网络安全信息表中指出：“恶意网络行为者可以利用这些漏洞进行远程代码执行或其他不利影响，这通常会危及设备并成为大规模网络入侵的第一步。 ”
“CやC++などの一般的な言語は、メモリ管理に関して多くの自由度と柔軟性を提供し、メモリ参照の必要なチェックを実行するプログラマに大きく依存しています。
そのため、アプリケーション開発やシステムプログラミングの両方で、可能な限りメモリセーフ言語を使用することを推奨しています。
“NSAは可能な限りメモリセーフ言語の使用を推奨しています。
虽然大多数信息安全专家都熟悉这场关于内存安全语言的争论，但也许并非所有开发人员都熟悉。不过，考虑到这是一个存在了几十年的问题，也许他们应该这样做，正如 Java 的创建者 James Gosling 最近在一次关于如何以及为什么创建 Java 的讨论中指出的那样。
どちらかといえば、NSAの文書は、メモリセーフ言語への移行の背後にある技術的理由について、開発者に明確でわかりやすい言語の説明を提供しています。メモリ安全性に関して最も議論されている言語は、おそらくCやC++の“代替”の主要な候補であるRustでしょう。
继 Android 开源项目之后，Linux 内核 最近将 Rust 作为 C 的第二语言引入。这些项目不会替换旧的 C/C++ 代码，但会更喜欢 Rust 作为新代码。此外，Microsoft Azure CTO Mark Russinovich 最近呼吁所有开发人员在所有新项目中使用 Rust 而不是 C 和 C++。
“これらのタイプのメモリ問題を悪用することで、ソフトウェア使用の通常の期待に縛られない悪意のあるアクターは、プログラムに異常な入力を入力し、予期しない方法でメモリへのアクセス、書き込み、割り当て、解放を引き起こす可能性があります。
但是——正如专家在关于 Rust 和 C/C++ 的辩论中指出的那样 ——美国国家安全局警告说，简单地使用内存安全语言并不能默认排除将内存错误引入软件。此外，语言通常允许不是用内存安全语言编写的库。
“メモリセキュリティ言語を使用しても、メモリ管理は完全にメモリセキュリティではありません。ほとんどのメモリセキュリティ言語は、ソフトウェアが特定のタスクを実行するために安全でないメモリ管理機能を実行する必要があることを認識する。したがって、非メモリ安全と考えられるものを使用し、プログラマが潜在的に安全でないメモリ管理タスクを実行できるようにすることができる。
“いくつかの言語では、プログラマやプログラムのレビュー者が安全でないことを認識できるように、メモリが安全でないものは明示的にコメントする必要があります。メモリ安全言語は、非メモリ安全言語で書かれたライブラリを使用することもできるので、安全でないメモリ機能を含むことができる。メモリ安全性メカニズムを含むこれらのアプローチは、本質的なメモリ安全性を覆しますが、メモリ問題が発生する可能性のある場所を特定するのに役立ち、コードのこれらの部分を追加の精査が可能です。
NSA 指出，某些内存安全语言可能会以性能成本为代价，这需要开发人员学习一门新语言。它还指出开发人员可以采取一些措施来强化非内存安全语言。例如， Google 的 Chrome 团队正在探索多种强化 C++ 的方法，但这些方法也会带来性能开销。在可预见的未来，C++ 将保留在 Chrome 的代码库中。
NSAはメモリの問題を検出するために静的および動的アプリケーションセキュリティテストを推奨している。また、コードが実行される場所を制限するCFG（Control Flow Guard）などのメモリ強化手法を探索することも推奨しています。同様に、アドレスレイアウトランダム化（ASLR）およびデータ実行（）を使用することが推奨される。
メモリセキュリティとは何で、なぜ重要なのか？
本文は翻译Google翻译加持から来ています。
出典www.memorysafety.org
前の記事：メモリセーフティとは何か、なぜ重要なのか？
原文へのリンク：https//www.memorysafety.org/docs/memory-safety/
メモリ安全性は、プログラマがメモリの使用方法に関連する特定の種類のエラーを発生させるのを防ぐいくつかのプログラミング言語の特性です。メモリセキュリティの脆弱性はしばしばセキュリティ上の問題であるため、メモリセーフ言語は非メモリセーフ言語よりも安全です。
メモリセーフには、Rust、Go、C#、Java、Swift、Python、JavaScriptがあります。メモリが安全でない言語には、C、C++、アセンブリ言語などがある。
メモリセキュリティの脆弱性
メモリセキュリティの脆弱性を理解するために、多くのユーザーのToDoリストを維持するアプリケーションの例を見てみましょう。メモリが安全でないプログラムで発生する可能性のある、最も一般的なタイプのメモリ安全エラーのいくつかを見ていきます。
国境を越えた読み書き
10項目のToDoリストがあり、11項目目を要求したらどうなるでしょうか。間違いを犯したに違いない。否定の最初の項目を要求すると、エラーも発生するはずです。
このような場合、メモリ安全でない言語は、プログラマがリストの有効な内容の直前または直後に存在するメモリ内容を読み取ることを可能にする。これを境界読み取りと呼ぶ.リストの最初の項目の前のメモリは、他の人のリストの最後の項目になる可能性があります。リストの最後の項目の後のメモリは、他の人のリストの最初の項目になる可能性があります。このメモリへのアクセスは重大なセキュリティホールです!プログラマは要求された項目のインデックスとリストの長さを慎重に調べることでオーバーランを防ぐことができますが、プログラマは間違いを犯します。デフォルトでこの種のエラーからあなたとユーザーを保護するメモリセーフ言語を使用することをお勧めします。
メモリセーフ言語では、コンパイル時にエラーを起こしたり、実行時にクラッシュしたりします。プログラムクラッシュは深刻に見えますが、ユーザーがお互いのデータを盗むよりはましです。
密接に関連した脆弱性は、境界線書き込みです。この場合、ToDoリストの11番目の項目、または否定の最初の項目を変更しようとしたとします。他の人のリストを変更しています!
リリース後の利用
ToDoリストを削除し、そのリストの最初の項目をリクエストしたとします。削除されたリストから項目を取得できないはずなので、明らかにエラーが発生するはずです。メモリが安全でない言語は、プログラムが完了したメモリを取得し、他の目的に使用できるようにする。メモリ内の場所に他の人のToDoリストが含まれます。これをリリース後のエクスプロイトと呼びます。
メモリセキュリティの脆弱性はどれくらい一般的か？
极其。最近的一项研究发现，iOS 和 macOS 中 60-70% 的漏洞是内存安全漏洞。Microsoft 估计，在过去十年中，其产品中的所有漏洞中有 70% 是内存安全问题。谷歌估计 90% 的 Android 漏洞都是内存安全问题。对被发现广泛被利用的 0-day 的分析发现，超过 80% 的被利用漏洞是内存安全问题1。
2003 年的Slammer 蠕虫(这是一种专门衡量软件漏洞的方法，它不包括诸如凭据网络钓鱼之类的非常普遍的事情。)是缓冲区溢出（越界写入）。WannaCry（越界写入）也是如此。针对 iPhone的Trident 漏洞利用了三个不同的内存安全漏洞（两个释放后使用和一个越界读取）。HeartBleed是内存安全问题（越界读取）。Android 上的Stagefright也是如此（越界写入）。glibc 中的Ghost漏洞？你打赌（越界写）。
由于 C 和 C++ 不是内存安全的，因此这些漏洞以及利用其他漏洞成为可能。编写大量 C 和 C++ 的组织不可避免地会产生大量漏洞，这些漏洞可直接归因于缺乏内存安全性。这些弱点被利用，给医院、持不同政见者和卫生政策专家带来危险。使用 C 和 C++对社会不利，对您的声誉不利，对您的客户不利。
メモリが安全でない言語に関連するその他の問題は何ですか？
メモリが安全でない言語は、安定性、開発者の生産性、アプリケーションのパフォーマンスにも悪影響を及ぼします。
メモリが安全でない言語はエラーやクラッシュが多く発生する傾向があるため、アプリケーションの安定性に大きな影響を与えます。クラッシュがセキュリティに敏感でなくても、ユーザーにとっては本当に悪いエクスペリエンスです。
さらに悪いことに、開発者がこれらのエラーを追跡するのは難しい。メモリの破損は、通常、エラーの実際の場所から遠く離れた場所でクラッシュを引き起こします。マルチスレッドが関与する場合、スレッドの実行時間のわずかな違いが追加のエラーを引き起こす可能性があり、エラーの再現が困難になります。その結果、開発者は通常、メモリ破損エラーの原因を特定するためにクラッシュレポートを何時間も見つめなければなりません。これらのバグは何ヶ月も修正されないことがあり、開発者はバグがあると完全に確信していますが、原因の発見と修正を進める方法を知りません。
最後に、パフォーマンスです。過去数十年の間、CPUは1年か2年ごとに高速化することが期待できます。これはもはや当てはまりません。代わりに、CPUはより多くのコアを持っている。追加カーネルを利用するには、開発者はマルチスレッドコードを書く必要がある。
残念ながら、マルチスレッドはメモリ安全性の欠如に関連する問題を悪化させるため、CおよびCでマルチコアCPUを活用する努力はしばしばトリッキーです。例えば、マルチスレッドのRustでシステムを書き直す前に、MozillaはFirefoxのC CSSサブシステムにマルチスレッドを導入しようと何度も試みましたが、失敗しました。
正しい道とは何か。
メモリセキュリティ言語を使う!多くの素晴らしい選択肢があります。オペレーティングシステムカーネルまたはWebブラウザを書くか。Rustを参照。iOSとmacOS用にビルド？Swiftは可能です。Webサーバー？Goは良い選択です。これらはほんの一部の例ですが、他にも優れたメモリセキュリティ言語がたくさんあります（そして他にも素晴らしいユースケースがたくさんあります!）。
組織で使用するプログラミング言語の変更は簡単ではありません。これは、採用時に求めるスキルを変えることを意味し、従業員を再訓練することを意味し、大量のコードを書き直すことを意味します。しかし、長期的にはこれが必要であると考えているので、新しいプログラミング言語を採用する代替案が成功しない理由を説明したいと思います。
安全でない言語を使用することが脆弱性を生み出すことを当然と思っているのであれば、プログラミング言語を完全に変更することなく、このリスクを軽減するためのテクニックを採用できないかという質問があります。答えはイエスだ。安全でない言語で書かれたすべてのプロジェクトが安全で信頼性が低いわけではない。
安全でない言語を使用するリスクを軽減する方法は以下のとおりです。
- 使用一些现代 C++ 惯用语可以帮助生成更安全可靠的代码
- 使用fuzzers和sanitizers帮助在将错误投入生产之前找到它们
- 脆弱性の悪用を容易にするエクスプロイト軽減策を使用する
- 権限分離、脆弱性が悪用されても爆発半径が小さくなる
これらのプラクティスは、安全でない言語を使用するリスクを有意義に低減します。言語を変更するよう説得できず、CやC++を書き続ける予定の場合は、これらのプラクティスを採用することが不可欠です。残念ながら、それらも深刻に不十分です。
浏览器和操作系统开发人员是开发现代 C++ 惯用语、fuzzers、sanitizers、漏洞利用缓解和权限分离技术的最前沿人员——正是我们在开始时通过有关内存安全问题普遍性的统计数据强调的群体。尽管这些团队在这些技术上进行了投资，但他们使用不安全的语言却拖累了他们。在大型黑客大赛pwn2own上，2019年这些产品被利用的漏洞中有一半以上是由于缺乏内存安全，除了一个例外，每一次成功的攻击都至少利用了一个内存安全漏洞。
CとC++をあきらめることは本当に可能ですか？
うまくいけば、CやC++のような安全でない言語が当社製品の多くの安全でない原因であり、リスクを軽減するためにできることはいくつかありますが、それを排除することはできません。これらすべては、使用するプログラミング言語を変更し、数百万行のコードを生成することは圧倒的に巨大な作業であると感じるかもしれません。それを管理可能な部分に分解することで、進歩を始めることができます。私たちの目標は、世界をビッグバン的に書き換えることではなく、リスクを低減する進歩です。
まず、全く新しいプロジェクトです。これらの場合は、単にメモリセーフ言語を使用することを選択できます。これらのプロジェクトは、コードを書き直す必要がないため、リスクが最も低いですが、このようなプロジェクトでは、新しいプログラミング言語をサポートするためにテストやデプロイメントインフラストラクチャを改善する必要があります。これはChromeOSのCrosVM（オペレーティングシステムの全く新しいコンポーネント）で採用されているアプローチです。
如果您没有新项目，下一个寻找机会使用内存安全语言的地方是现有项目的新组件。一些内存安全语言对与 C 和 C++ 代码库（例如 Rust 和 Swift）的互操作提供了一流的支持。这需要稍高的初始投资，因为它需要集成到构建系统中，以及使用新语言为需要跨越两种语言之间的边界传递的对象和数据构建抽象。当WebAuthn作为 Firefox 的一个新组件实现时，以及一个支持在 Rust 中编写 Linux 内核模块的项目，就成功地使用了这种策略。
最初の2つのアプローチに共通するのは、新しいコードを扱うことです。これは、既存のコードとの相互作用点を明確に定義し、何も書き直すことなく作業を開始できるという利点があります。また、出血を止める機会もあります。安全でない言語を使用する新しいコンポーネントはなく、既存のコードを徐々に処理します。メモリセーフ言語を使用し始めるための自然な新しいコンポーネントがないプロジェクトでは、採用はさらに困難です。
この場合、安全でない言語を安全な言語に書き直すために、既存のコンポーネントを探す必要があります。選択するコンポーネントは、パフォーマンス、セキュリティ、またはコードのメンテナンスが難しすぎるため、すでに書き直すことを検討しているコンポーネントであることが最善です。プロジェクトを成功させ、できるだけ早くリリースするために、最初のメモリセーフ書き換えにはできるだけ小さなものを選ぶようにしてください。これにより、書き換えに固有のリスクを最小限に抑えることができます。FirefoxのCSSエンジンをRustで書き直したStyloは、このアプローチの成功例である。
組織に最適なアプローチが何であれ、成功の可能性を最大化するために留意すべきことがいくつかあります。1つ目は、多くのチームメンバーにとって新しい言語でコードレビューとガイダンスを提供できる社内のサポーターとシニアエンジニアを確保することです。これの自然な延長は、新しい言語で作業するエンジニアが、書籍、トレーニング、社内ガイドなどのリソースを利用できるようにすることです。最後に、ビルドシステム、テスト、デプロイ、クラッシュレポート、その他の統合など、新しい言語が古い言語と同じ共有インフラストラクチャを持っていることを確認する必要があります。
結論：結論
新しいプログラミング言語を採用し、それに移行するプロセスを開始するのは簡単なことではありません。組織全体の計画、リソース配分、そして最終的には投資が必要です。これらのことを考える必要がなければ、人生はもっと楽になるでしょう。残念ながら、データのレビューでは、セキュリティ上重要なプロジェクトで安全でない言語を使用し続けることは考えられないことが明らかになりました。
データは、プロジェクトがCやC++などの安全でない言語を使用すると、多数のセキュリティ脆弱性に悩まされることを何度も証明しています。どんなに優秀なエンジニアでも、パーミッション削減やエクスプロイト軽減に投資しても、メモリ安全でない言語を使用するとエラーが多すぎるだけです。これらのエラーはセキュリティ、安定性、生産性を大幅に低下させます。
幸いなことに、現状に満足する必要はありません。ここ数年で、Rust、Swift、Goなど、CやC++に代わる素晴らしい代替手段が登場しました。つまり、今後何年もの間、メモリ破損の脆弱性をアホウドリのように首に巻く必要はありません。多要素認証や転送中のデータの暗号化がないため、安全でない言語を選択することは過失とみなされる日が来ることを期待しています。
ありがとうアレックス·ガイナー
经许可，此解释基于 Alex Gaynor 的博客文章工程副总裁的内存不安全简介。
本文の概要
この2つの翻訳から何かが得られることを願う。