「解放後使用」の定義と任意のコードが実行される仕組み
ウェブセキュリティの非営利団体OWASP（オワスプ、Open Worldwide Application Security Project）は、解放後使用について、プログラムがヒープ領域に確保したメモリーを解放または削除した後も、そのメモリーを参照し続けることで起きる問題と定義している。
プログラムのコードが、すでに解放されたメモリーを指すポインターを使えば、システムがどのように動作するか分からない「未定義動作」が起きる可能性がある。
さらにOWASPによると、多くの場合、攻撃者が指定した値を指定したメモリー領域に書き込める「write-what-where」と呼ばれる状態につながる可能性もある。
被害が出ない場合もあるが、システムが侵害され任意のコードを実行されることも
もちろん、解放後使用のエラーが発生しても、常に目に見える被害が起きるとは限らない。場合によっては、利用者が確認できる影響がまったく出ないこともある。
しかし、そのエラーによってプログラムが停止すれば、実際の問題になる。さらに深刻なのは、攻撃者が別のメモリー関連の攻撃手法と組み合わせ、システムを侵害できる場合である。その結果、データが壊れたり、攻撃者が任意のコードを実行したりするおそれがある。
関数ポインターの書き換えと任意のコードの実行
MITREが公開しているCommon Weakness Enumeration（CWE、共通脆弱性タイプ一覧）でも、解放後使用の仕組みが説明されている。
それによると、解放されたメモリー領域を整理してまとめる処理が行われる前に悪意あるデータが入力されると、攻撃者は任意の場所に任意の値を書き込める仕組みを悪用し、任意のコードを実行できる可能性がある。
例えばC++では、新たに割り当てられたメモリーにクラスのデータが入っている場合、ヒープ領域の各所に関数ポインターが配置されることがある。
そして、その関数ポインターの1つが、攻撃用コードであるシェルコードの有効なアドレスに書き換えられると、攻撃者が任意のコードを実行できる。
Chromeで解放後使用が頻繁に見つかる2つの理由
ここに問題の核心がある。Chromeは、主にC++で書かれた非常に大規模なソフトウェアである。
C++のコードでは、すでに無効になったメモリー領域を指し続ける「ダングリングポインター」が見つかること自体は珍しくない。特に、コードが極めて複雑で、実行中に状態が頻繁に変化する場合は、こうした問題が起きやすくなる。
しかも、Chromeほどコードの規模が大きくなれば、問題が見つかる可能性もそれだけ高まる。
Chromeは複数のプロセスを使って動作するうえ、複雑なウェブ標準に対応しなければならない。こうした標準を処理するには、実行中にメモリーを動的に割り当てたり、複数の処理の間で共有したりする必要がある。そのため、解放後使用につながる不具合が入り込む余地も増える。
これが、Chromeで解放後使用の脆弱性が頻繁に見つかる第1の理由である。
一見悪いニュースに見えるが、攻撃者より先にグーグルが見つけ利用者を守っていることを示す
一方、もう1つの理由も忘れてはならない。グーグルが、こうした脆弱性を見つけることに長けているからである。
利用者から見れば、多数の脆弱性が次々に公表されることは、悪いニュースのように感じられるかもしれない。しかし、実際には、問題が見つかり、修正されていること自体は良いことだ。
攻撃者が脆弱性を先に発見し、利用者への攻撃に使うよりも、グーグルの研究者がAIの支援を受けた自動ファジングシステムを使って先に発見する方が、はるかに望ましい。利用者にとっても同じだ。
要するに、グーグルは脆弱性を見つけて修正し、利用者を守ろうとしている。今回も、他のChromeセキュリティアップデートと同様に、新しいバージョンは順次自動配信され、修正も自動的に適用される。
