Googleは、「Chrome」のコードベースに存在する深刻なセキュリティバグの約70%が、メモリー管理とメモリー安全性に関する問題であることを明らかにした。
70%の約半数は解放済みメモリー使用の脆弱性だった。これは、ポインターの管理が不十分で、Chromeの内部コンポーネントに攻撃を仕掛ける隙を与えてしまうセキュリティ上の問題だ。
これらの統計は、Chromeの安定版チャネルに影響する、2015年以降の深刻度が「high」か「Critical」に分類されたセキュリティ上の脆弱性912件を分析して得られたものだ。
この数字は、Microsoftが公表しているものとも一致する。2019年2月に開催されたあるセキュリティカンファレンスでは、Microsoftのエンジニアが、過去12年間に提供された同社製品のセキュリティ更新プログラムで修正された脆弱性のうち、70%がメモリー安全性の問題だったと述べている。
両社が抱えている共通の問題は、コードベースで使われている2つの主要言語(具体的には「C」と「C++」)の安全性が懸念されることだ。
Chromeのメモリーの問題に対するGoogleの取り組み
Googleによれば、2019年3月時点でChromeで見つかった深刻度が「Critical」の脆弱性130件のうち、125件がメモリー破損関係の問題だったという。これは、他の種類のバグの修正が進んでいる一方で、メモリー管理の問題は依然として改善されていないことを示しているかもしれない。
メモリー管理関係の脆弱性が大きな問題になっていることなどから、最近では、Chromeの開発者は「Rule Of 2」と呼ばれるルールに従うことになっている。
このルールは、新機能を実装する際には、書いているコードが以下の3つの条件のうち2つに当てはまってはならないというものだ。
- 信頼できない入力を処理するコードである
- サンドボックスなしで実行されるコードである
- 安全でないプログラミング言語(CまたはC++)で記述されたコードである
サンドボックスの恩恵は限界
これまで、Googleのエンジニアは、Chromeでサンドボックスを積極的に利用するアプローチを強く支持してきた。Chromeでは何十ものプロセスがそれぞれのサンドボックスに隔離されており、最近ではアクセスしている各サイトのリソースをサンドボックス化されたプロセスに隔離する「サイト分離」機能も導入されている。
しかし、Googleのエンジニアは、パフォーマンスを考慮すると、Chromeのコンポーネントをサンドボックス化するアプローチのメリットは限界に達しており、今後は新しいアプローチを模索する必要があると話すようになっている。
Googleによれば、同社は今後、メモリー関係の脆弱性に対してより優れた保護を提供するC++のカスタムライブラリを開発し、Chromeのコードベースに使用する計画だという。
また、「許容できるパフォーマンス、メモリー、バイナリーサイズの範囲で、安定性への悪影響を最小限に抑えつつ、悪用可能な解放済みメモリー使用の脆弱性をセキュリティ上の問題がないクラッシュに変える」ことを目指す「MiraclePtr」プロジェクトも進められている。
さらにGoogleは、可能なところでは「安全」な言語を使用することを模索すると述べている。言語の候補には、「Rust」「Swift」「JavaScript」「Kotlin」「Java」などが挙がっている。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。