米国サイバーセキュリティ・インフラストラクチャ・セキュリティ局（CISA）は、172の主要なオープンソースプロジェクトと、それらがメモリ欠陥の影響を受けやすいかどうかを調査した調査結果を発表した。
CISA、連邦捜査局（FBI）、オーストラリア（ASD、ACSC）、カナダの組織（CCCS）が署名したこの報告書は、2023年12月に発表された「メモリーセーフ・ロードマップの事例」に続くもので、メモリーセーフ・コードの重要性に対する認識を高めることを目的としている。
メモリーセーフ
メモリセーフ言語とは、バッファオーバーフロー、use-after-free、その他のタイプのメモリ破壊など、メモリに関連する一般的なエラーを防止するように設計されたプログラミング言語である。
これは、プログラマーが安全なメモリ割り当てと割り当て解除のメカニズムを実装する代わりに、メモリを自動的に管理することで実現される。
安全な言語システムの最新の例としては、Rustのボロー・チェッカーがあり、データ・レースを排除している。Golang、Java、C#、Pythonのような他の言語は、ガベージコレクションを通じてメモリを管理し、悪用を防ぐために解放されたメモリを自動的に再要求する。
メモリ安全でない言語とは、組み込みのメモリ管理メカニズムを提供せず、開発者にこの責任を負わせ、エラーの可能性を高めている言語である。C、C++、Objective-C、Assembly、Cython、Dなどがその例である。
広く使われているオープンソース・コードの安全性
この報告書は、172の広く展開されているオープンソースプロジェクトを調査し、半数以上にメモリ安全でないコードが含まれていることを発見した研究を紹介しています。
本レポートの主な調査結果は以下の通りです：
- 分析された重要なオープンソースプロジェクトの52%にメモリ安全でない言語で書かれたコードが含まれている。
- これらのプロジェクト全体のコード行数（LoC）の55％がメモリ・アンセーフ言語で書かれている。
- 最大規模のプロジェクトは、メモリ・アンセーフ言語で書かれている割合が高い。
- 総 LoC で最大の 10 プロジェクトのうち、メモリ非安全な LoC の割合はそれぞれ 26%を超えている。
- これらの大規模プロジェクトにおけるメモリアンセーフLoCの割合の中央値は62.5%で、94%を超えるプロジェクトが4つある。
- メモリ・セーフ言語で書かれたプロジェクトでさえ、メモリ・アンセーフ言語で書かれたコンポーネントに依存していることが多い。
調査されたセットからのいくつかの顕著な例は、Linux（安全でないコードの比率95％）、Tor（安全でないコードの比率93％）、Chromium（安全でない比率51％）、MySQL Server（安全でない比率84％）、glibc（比率85％）、Redis（比率85％）、SystemD（65％）、Electron（47％）です。
CISA
CISAは、ソフトウェア開発者は、リソースの制約や性能要件など、しばしばメモリ非安全言語の使用を余儀なくされる複数の課題に直面していると説明している。
これは、ネットワーキング、暗号化、オペレーティング・システム機能などの低レベルの機能を実装する場合に特に当てはまります。
「多くの重要なオープンソースプロジェクトが部分的にメモリ非安全言語で書かれており、限られた依存関係分析によると、プロジェクトは依存関係を通じてメモリ非安全言語で書かれたコードを継承していることがわかりました」と、CISAは報告書で説明しています。
「パフォーマンスとリソースの制約が重要な要素である場合、メモリ・アンセーフ言語が使用され続けることが予想されます。
CISAはまた、開発者が特定の要件を満たすために、誤って、あるいは意図的に、メモリ安全性機能を無効にしてしまうことで、理論上より安全なビルディング・ブロックを使用していてもリスクが生じるという問題にも言及している。
最終的にCISAは、ソフトウェア開発者に対し、Rust、Java、GOなどのメモリ安全言語で新しいコードを記述し、既存のプロジェクト、特に重要なコンポーネントをこれらの言語に移行することを推奨している。
さらに、安全なコーディング手法に従うこと、依存関係を注意深く管理し監査すること、メモリ安全性の問題を検出し対処するために、静的解析、動的解析、ファズテストを含む継続的なテストを実施することを推奨する。
Comments