Java／Rust／Kotlin のメモリセーフ機能：C／C++ と安全性を比較してみる

Shift to Memory-Safe Languages Gains Momentum

2022/12/07 DarkReading — 今週に、ソフトウェア・セキュリティの専門家たち発表したところによると、リモートからの悪用が可能で、野放し状態での攻撃の大部分に関与している、きわめて深刻な脆弱性のグループに対して、ソフトウェア業界は前進しているようだ。この脆弱性グループとは、いわゆるメモリ安全性の問題である。具体的には、バッファオーバーフロー／ユースアフターフリーなどを含むものであり、ソフトウェア会社が公表するアプリケーション・セキュリティ問題の大半を占めるものだ。今回の最新データでは、Java／C#／Rust などの、メモリ安全性の高い言語の使用が増加したことで、このクラスの脆弱性全体が急速に減少していることが示されている。

先週に Google が発表した Android OS の最新バージョンでは、Java／Rust／Kotlin などのメモリセーフ言語で書かれた新しいコードが、C／C++ などの従来からの言語よりも多くなった。その結果として、メモリセーフに関連する脆弱性が、この３年間で 223件 から 85件に減少したことが判明している。

Google の Software Engineer である Jeffrey Vander Stoep は、「私たちは、最も深刻な脆弱性から順に、それらが所属するグループ全体を排除することに、引き続き注力していく。メモリ安全性の脆弱性が、より少なくなるにつれて、研究者たちのコミュニティは、他のクラスの脆弱性の発見に注力することが予想される」と述べている。

何十年にもわたって、C／C++ はソフトウェア業界の主力プログラミング言語として使用されてきた。そして、C#／Go／Java／Python／Ruby／Rust／Swift といった最新の言語も、メモリ保護機能を備えていない。

アプリケーション・セキュリティ企業である Veracode のレポート State of Software Security Vol. 11 によると、C++ で書かれたアプリケーションの 59% には、重大かつ深刻な脆弱性が存在するが、JavaScript は 9% であり、Python は 10% であることが判明している。

バッファオーバーフローとワームを許す欠陥

欠陥のあるコードを、プログラマーが作成しやすいという状況が、大規模なソフトウェア企業にとって大きな問題になっている。たとえば Microsoft のケースでは、2018年までの同社のソフトウェアで発見された脆弱性のうち、メモリ安全性の問題が 70％ を占めていたことが判明している。Software Resilience Engineer である Alex Gaynor の 2020年の調査によると、多種多様なエコシステムにおけるメモリ安全性の問題は、すべての脆弱性の 60%〜70% を占めているとされる。

また、この欠陥は、アプリケーションを攻撃するために容易に悪用できるため、相当数の侵害の根本原因になっていると、Veracode の CEO である Chris Wysopal は述べている。彼は、「メモリ破壊の問題は、最も深刻度の高い欠陥の１つであり、攻撃者がコードを実行することで、アプリケーションの完全な制御を奪われるケースが多い。最悪の場合には、その脆弱性から作られたワーム・エクスプロイトにより、他のインスタンスが攻撃されることもある」と指摘している。

Android 開発におけるメモリ安全性言語への移行に関する、最近の Google のブログ記事では、「メモリの安全性に関連する脆弱性は、現在の Android で公開されている問題の 36％ を占めるのみだが、深刻なセキュリティ脆弱性の 86％ と、リモートから悪用される問題の 89％ を占める」と指摘されている。

安全な言語への切り替え

そのため、Google などは開発者に対して、メモリ安全性の高い言語を採用するよう促している。

Google は、「現在では、新規コードの作成において、C／C++ 占める割合は半分弱に過ぎない。実際ぼところ、最新版の Android 13 では、コードの大半がメモリセーフな言語で書かれるようになり、多くの開発者が C／C++ に代わって Rust を使用している。Rust は、安全なコードを作成することに重点を置いた、効率的なプログラミング言語である」と述べている。

米国国家安全保障局 (NSA) も、メモリセーフなプログラミング言語の採用を、企業に対して促している。

しかし、メモリ安全性の高い言語に、変更するだけでは十分ではない。たしかに、それぞれの言語の保護レベルに応じて、プログラマーは安全ではないコードを書き難くなる。そのため、NSA は開発者に対し、コンパイラー・オプションからスタティック・スキャナー／ランタイム解析にいたるまで、さまざまなアプリケーション・セキュリティ・ツールを用いて、アプリケーションを可能な限り堅牢化することも推奨している。

NSA のレポートには、「ソフトウェア解析ツールは、メモリ管理に関する問題の、多くの事例を検出することが可能だ。動作環境オプションによっても、ある程度の保護を提供することが可能だが、メモリセーフなソフトウェア言語が提供する固有の保護は、ほとんどのメモリ管理問題を防止／軽減できる」と記されている。

結局のところ、メモリセーフ言語は、ソフトウェア脆弱性の問題に対する独立した解決策とはならないが、最も深刻なプログラミング・エラーを、開発者が回避するための指針を与えるものだと、Veracode の Wysopal は述べている。

彼は、「メモリセーフ言語の使用方法が異なるため、一般的なレベルで、脆弱性の数が少ないと言うのは難しい。しかし、２つの異なる言語を用いて、まったく同じタスクを達成する際に、一方がメモリセーフであれば、そちらの方が脆弱性が少なく、深刻な脆弱性も少ないと予想される」と指摘している。

この記事を訳して、お隣のキュレーション・チームに見てもらったら、みなさん強く同意していました。やはり、メモリ破壊の脆弱性が、次から次へと発見されるという状況が続いているようです。2022年10月12日の「Chrome 106 の深刻な脆弱性６件が FIX：なかなか止まらない use-after-free 欠陥」などは、この問題を指摘する顕著な例と言えるでしょう。Quora に、「Chrome は C++、Assembly、Pythonで書かれている」 という記事を見つけましたが、これではメモリ破壊は防げないということなのでしょう。この記事の元データは、Google の Memory Safe Languages in Android 13 です。よろしければ、ご参照ください。