「Chrome」は「MiraclePtr」でさらに安全に ～Googleが「解放後メモリ利用」対策を開設

公式ブログ「Google Online Security Blog」

　「Google Chrome」では継続的なセキュリティアップデートが行われているが、そこで修正される脆弱性の多くは「解放後メモリ利用」（Use-after-Free）と呼ばれるタイプのメモリ安全バグだ。開発チームはこの解放後メモリ利用バグに対し、どのような対策を講じているのだろうか。米国時間9月13日に公開された公式ブログ「Google Online Security Blog」の記事では、その詳細が紹介されている。

　メモリが必要になると、「Chrome」はOSに対しメモリの確保（Allocate、Alloc）を依頼し、ポインター（Pointer、Ptr）介してアクセスする。確保したメモリが不要になるとそれを開放（Free）し、OSに返却する――というのがメモリ管理の流れだ。メモリを解放した後のポインターは、その指し示すメモリ領域に何が格納されているのかわからない（未定義）ため、基本的に再利用はしない。

　しかし、手違いにより「解放後メモリ利用」が行われてしまうことがある。ポインターは実行可能な処理（関数）を指している場合があり、これがなんらかの方法で悪意ある処理に置き換えられてしまうと、脆弱性の原因となってしまう。

　小規模なプロダクトならば、この問題は気を付けていれば十分避けられる。しかし、製品の規模が大きくなり、多数のプログラマーが関わるようになると、混入を防ぐのは難しくなる。実際、「Chrome」で悪用可能な既知の不具合の半分は「解放後メモリ利用」となっている。

「Chrome」で対処されているバグの種類

　そこで、開発チームはいくつかの対策を講じている。

　1つ目は、もし脆弱性が悪用されても、他の部分への影響を最小限に抑えることだ。たとえば「悪意あるコンテンツを読み込むだけで悪用が可能」な脆弱性の場合、レンダラープロセスが乗っ取られてしまったことになる。しかし、レンダラープロセスと他のブラウザープロセスを分けておけば、被害をレンダラープロセスに封じ込めることができる。他の「Chrome」プロセスやOSの脆弱性を巧妙につなぎ合わせない限り、破壊的な攻撃は行えない。この方法は一般的に「サンドボックス」と呼ばれる。

サンドボックスによる脆弱性の影響の軽減

　2つ目は、「解放後メモリ利用」のバグ自体をなるべく減らすことだ。これに用いられているのが「MiraclePtr」と呼ばれる技術で、プログラマーが自分でメモリをAlloc、Freeする代わりに、専用のスマートポインター型（raw_ptr<T>）でメモリ管理を自動化する。同社はさまざまなアルゴリズムを比較検討した結果、「BackupRefPtr」と呼ばれるアルゴリズムが「Chrome」には最適であると結論付け、これを独自開発の効率的なメモリアロケーター「PartitionAlloc」と組み合わせて利用しているという。

　「PartitionAlloc」はメモリ領域が不要（参照カウントが0）になると即時にそれを解放せず、一度「隔離」する。隔離されたメモリは「解放後メモリ利用」を悪用する機会を減らすだけでなく、もしアクセスされるとクラッシュしてログに記録するため、アクセスの原因を突き止めるのに役立つ（診断性の向上）。

参照カウントベースのスマートポインター「raw_ptr<T>」

　残念ながら、「MiraclePtr」などのセキュリティ保護策には若干のペナルティがある。たとえば、「MiraclePtr」の採用はWindowsで4.5～6.5％、Android1で3.5～5％ほど、ブラウザープロセスのメモリ使用量を増やしてしまう。また、パフォーマンス面でも不利になる。

　しかし、メモリ使用量の問題は「PartitionAlloc」の改善などでカバー。パフォーマンスに関しては、最適化技術を用いた改善に努めているとのこと。オーバーヘッドを最小限に抑えるため、クラス・構造体ポインターフィールドのみを保護するなどの配慮もしている。大きな問題がなければ、スタックポインターなどへ保護策を拡大することも検討しているとのこと。

　メインスレッド競合の増加（7％以下のオーバーヘッド）には有効な対策がないようだが、それもセキュリティ強化の恩恵に比べれば甘受できる水準にあると判断されたようだ。

　もともと「MiraclePtr」はメモリ安全性のために導入されたものだが、クラッシュによる診断性向上で、以前は検出されなかった多くのバグが発見・修正されているのは僥倖といえよう。同社は「MiraclePtr」のクラッシュレポートをさらに有益で実用的なものにする取り組みを進めていくとしている。