本格的なソフトウェア開発者の間で長年懸念されてきたメモリの安全性は、ついに主流のスターの座を獲得しました。
製品テストに焦点を当てた 87 年の歴史を持つ非営利団体である Consumer Reports は、今週、メモリの安全性に関するレポートを発表しました。 この出版物は、消費者に焦点を当てたオンラインセキュリティガイドの限界について内部で話し合った後、この高度に技術的な懸念をどのように調査するようになったかを説明することで、このトピックの予想外の報道を認めました.
このトピックは、水曜日に USENIX Enigma 2023 カンファレンスで取り上げられました。パネリストの Yael Grauer (Consumer Reports Digital Lab の副コンテンツ エディター)、Amira Dhalla (Consumer Reports の動員、コミュニティ エンゲージメント、およびオペレーションのアソシエイト ディレクター)、Alex Gaynor (ソフトウェアセキュリティ エンジニアで Fish in a Barrel の創設者) と Josh Aas (非営利の Internet Security Research Group の共同創設者兼エグゼクティブ ディレクター) は、メモリの安全性に関する脆弱性を減らすために何ができるかについて話しました。
コンピューター コードが未定義のメモリ領域にアクセスしようとすると、メモリ エラーが発生します。つまり、ヒープ、スタック、または宣言されたデータの一部として明確に割り当てられていない、または確保されていないことを意味します。
メモリの安全性は複雑なトピックであり、研究論文で調査されています [PDF] 技術志向の人々の間で議論されました。 しかし、電子デバイスで実行されているソフトウェアまたはファームウェアのバグを通じて、デジタル技術を扱うすべての人に影響を与える可能性があります。 セキュリティの脆弱性の少なくとも 65% は、メモリ エラーが原因であると推定されています。
メモリの安全性は、主に C/C++ などの手動メモリ管理を伴うプログラミング言語の問題です。 不適切に管理されたメモリは、範囲外の読み取りと書き込み、解放後の使用エラーにつながる可能性があります。 この呪文の欠陥が悪用されると、攻撃者は影響を受けるデバイスを制御したり、データを盗んだりできる可能性があります。 論文を発表した米国国家安全保障局を懸念させるには十分な問題です。 [PDF] 昨年11月のメモリの安全性について。
ガベージ コレクションを組み込んでメモリを管理する最新のプログラミング言語 (Java、Python、JavaScript、Go など) は、プログラマがメモリ関連の欠陥を回避するのに役立ちます。
次に、比較的最近のプログラミング言語である Rust があります。Rust は、自動化されたガベージ コレクションのパフォーマンス コストを回避しながら、所有権の概念に依存してメモリの安全性を保証します。
メモリ セーフで高速なコードを記述できる可能性があるため、Rust は特定の分野で有名な原因の 1 つになっています。 昨年 9 月、Microsoft Azure の CTO である Mark Russinovich は、C/C++ で開始された可能性のある新しいソフトウェア プロジェクトでは、代わりに Rust を使用することを提案しました。
Russinovich の使命を支持して、セキュリティ会社 Chainguard は水曜日に、安全なコンテナ イメージを生成するために設計されたメモリ セーフな Linux “undistro” である Wolfi が、curl ネットワーク リクエスト ツールの Rust ベースの Hyper ライブラリを介してメモリ セーフな Rustls TLS ライブラリと HTTP を組み込んだと述べました。 .
Let’s Encrypt の開発で最もよく知られている Internet Security Research Group (ISRG) は、重要なオープン ソース コード (NTP、DNS、TLS など) の書き換えに焦点を当てた Prossimo と呼ばれるプロジェクトを通じて、メモリ セーフな TLS と HTTP を Wolfi に導入するのを支援しました。メモリセーフです。
ISRG の Josh Aas 氏は次のように述べています。 登録簿 彼は電話インタビューで、メモリの安全性に関する会話は出来事の合流点に由来すると信じていると語った。
「これまで以上にセキュリティに注目が集まっており、メモリの安全性が最大の問題の 1 つであるという理解が深まっていると思います」と彼は言いました。 「メモリの安全性に対処するのに役立つ最近のツールの成熟もあります。現在利用できるツールは、5 年前、10 年または 20 年前のツールよりもはるかに優れています。
「消費者レポートに関しては [exploring the topic]… メモリの安全性は、ソフトウェア エンジニアリングのやや難解な側面かもしれませんが、メモリの安全性の欠如によって引き起こされる問題は非常に深刻であるため、実際の消費者レベルの問題です。」
Aas は、Rust だけがメモリの安全性に対する答えであるとは考えていないことを明らかにしました。
「この会話で Rust をよく耳にするのは、Rust が C と同等またはそれ以上のパフォーマンスでメモリの安全性を提供するからです」と彼は言いました。 「しかし、Rust が対処する方法でパフォーマンスに非常に敏感でない場合は、多くの選択肢があります。」
C++ の作成者である Bjarne Stroustrup の、静的解析で規則が適用される場合、ISO 標準 C++ はメモリセーフである可能性があるという主張について尋ねられた Aas は、懐疑的な見方を示しました。
「現実世界の実用性を無視した非常に理論的な意味で、それは真実かもしれません」と彼は言いました。 「メモリセーフな C++ を書くことは、理論的には実際に可能かもしれません。しかし、それは私たちの世界での仕組みではありません。それを行うためのより良い方法があります。C++ は、メモリの安全性を提供するためにゼロから設計されたわけではありません。」
In Rust We Trust: Microsoft Azure CTO は C と C++ を避ける
続きを読む
木曜日に予定されている ISRG のブログ投稿で、 登録簿、Aas は、メモリ セーフ コードへの移行を検討している可能性のあるソフトウェア開発者やオープン ソース メンテナーにアドバイスを提供しました。
まず、彼は、開発者がメモリの安全でない言語で新しいプロジェクトを作成することによって、これ以上安全でないコードを作成するのをやめるようにアドバイスしています。これは Microsoft の Russinovich が言ったことです。
第二に、すべてを一度に書き直す必要はない、と彼は言います。 最初にセキュリティ クリティカルなモジュールに焦点を当てます。
第三に、多くの Rust ベースのモジュールには C API が付属しているため、オープンソースのメンテナーはメモリの安全性への移行を支援するために必ずしも Rust を学ぶ必要はないと彼は言います。
最後に、彼は、オープンソース コミュニティは、現在の現状 (メモリ エラーの果てしないパレード) が続く必要はないことを理解する必要があると主張しています。
「3 年前、これを行うべきかどうかについての会話がありました」と Aas 氏は言います。 「そして今、私たちは「すべき」を過ぎて、「どのように」に取り組んでいると思います。」 ®