CISA／FBI などの共同勧告：多くの OSS プロジェクトで Memory Unsafe 言語が使用されている

CISA: Most critical open source projects not using memory safe code

2024/06/26 BleepingComputer — 6月26日に米国の CISA が公開したレポートは、メモリ欠陥の影響の受けやすさについて、172件の主要オープンソース・プロジェクトを調べた結果をまとめたものだ。CISA／FBI／ASD (Australian Signals Directorate)／ACSC (Australian Cyber Security Centre)／CCCS (Canadian Centre for Cyber Security) によるレポートは、2023年12月に発表された “Case for Memory Safe Roadmaps” に続くものであり、メモリ・セーフなコードの重要性に対する、認識を高めることを目的としている。

メモリ・セーフ言語とは？

メモリ・セーフ言語とは、バッファ・オーバーフロー／use-after-free といった各種のメモリ破壊などを含む、メモリに関連する一般的なエラーを防止するように設計されている、プログラミング言語のことを指す。つまり、安全なメモリの割り当てと解放のメカニズムを、プログラマーが実装する代わりに、メモリを自動的に管理することになる。

安全な言語システムの最新の例としては、データ競合を排除した、Rust の borrow checker がある。Golang／Java／C#／Python のような言語も、garbage collection によりメモリを管理し、解放されたメモリを自動的に再要求して悪用を防いでいる。

メモリ・アンセーフな言語とは、メモリ管理に対するビルトイン・メカニズムを提供せず、その責任を開発者に負わせ、エラーの可能性を高めている言語のことを指す。その例として、C／C++／Objective-C／Assembly／Cython／D などが挙げられる。

広く使われているオープンソースのコードは安全ではない

広く展開されている 172のオープンソース・プロジェクトを調査したところ、半数以上にメモリ・アンセーフなコードが含まれていることが、CISA が公開したレポートにより判明した。このレポートに掲載されている主な調査結果は、以下の通りである：

  • 分析された重要なオープンソース・プロジェクトの 52%に、メモリ・アンセーフな言語で書かれたコードが含まれている。
  • これらのプロジェクト全体におけるコード行数 (LoC：lines of code) の 55％が、メモリ・アンセーフ言語で書かれている。
  • 最大規模のプロジェクトでは、メモリ・アンセーフ言語で書かれたコードが不釣り合いである。
  • LoC の合計が最も大きい 10個のプロジェクトのうち、メモリ・アンセーフな LoC の割合は 26％以上であった。
  • これらの大規模プロジェクトにおける、メモリ非安全 LoC の割合の中央値は 62.5%で、94% を超えるプロジェクトが４つもある。
  • メモリ・セーフ言語で書かれたプロジェクトでさえ、メモリ・アンセーフ言語で書かれたコンポーネントに依存していることが多い。

この調査結果における、いくつかの顕著な例と、安全ではないコード比率は以下の通りだ：

  • Linux (95％)
  • Tor (93％)
  • Chromium (51％) 
  • MySQL Server (84％) 
  • glibc (85％) 
  • Redis (85％)
  • SystemD (65％)
  • Electron (47％)
Summary of findings
調査結果の概要
Source: CISA

ソフトウェア開発者たちは、リソースの制約や性能要件などの複数の課題に直面しており、メモリ・アンセーフ言語の使用を余儀なくされていると、CISA は指摘する。特に、ネットワーキング／暗号化／OS 機能のような、低レベルの機能を実装する場合において、その傾向が顕著である。

CISA は、「我々の調査により、多くの重要なオープンソース・プロジェクトが、部分的にメモリ・アンセーフな言語で書かれていることが判明した。そして、限られた依存関係の分析から、多くのプロジェクトが依存関係を通じて、メモリ・アンセーフ言語で書かれたコードを継承していることも判った。パフォーマンスとリソースの制約が重要な要素である場合には、メモリ・アンセーフ言語が使用され続けることが予想される」と述べている。

同機関は、開発者が特定の要件を満たすために、意図的に、あるいは、誤って、メモリ安全機能を無効化してしまうことで、理論上では安全なビルディング・ブロックを使用していても、リスクが生じるという問題にも言及している。

CISA がソフトウェア開発者に対して推奨しているのは、Rust／Java／GO などのメモリ・セーフな言語で新しいコードを書き、既存のプロジェクト、特に重要なコンポーネントを、それらの言語に移行することだ。

さらに CISA は、安全なコーディング手法に従い、依存関係を注意深く管理／監査することを推奨し、メモリ安全性の問題を検出して対処するために、静的／動的解析や、ファズテストを含む継続的なテストを実施することも推奨している。

Memory Safe 言語は、CISA が推進する Secure-by-Design の一部であり、とても面白い着眼点だと感じています。そして、CISA が新たに公開したレポートは、主要 OSS プロダクトにおける、Memory Unsafe コードの比率を明らかにするものとなっています。予想通り、Linux／MySQL／glibc などが上位を占めています。コンパクトで高速なコードを書くために、C言語に依存している結果です。また、それぞれの言語における、プログラマー人口という問題もあるでしょう。とは言え、こうした調査により、現実の把握が進むのは、 とても良いことだと思います。よろしければ、2023/11/30 の「 CISA の Secure-by-Design 第一弾：安全な Web 管理インターフェイスのために」を、ご参照ください。