バッファオーバーフロー
より高度なヒープベースバッファオーバーフロー攻撃手法を説明する為の準備として、mallocのメモリ管理方法を説明する。なおメモリ管理方法の詳細はmallocの実装に依存するため、実行環境によって細かなところは下記の説明と異なる部分があるので注意されたい。
mallocは未使用なヒープ領域(の一部)をメモリプールとして管理しており、メモリプールは複数のchunkと呼ばれる単位からなっている。プログラム中でmallocが実行されるたびに、管理しているchunkの中から適切なサイズのものをプログラムに返す。適切なサイズのchunkがない場合は、システムコールにより新たなchunkを確保してプログラムに返す。mallocはchunkを(サイズ毎に異なる複数の)連結リストとして管理しており、chunkをプログラムに渡す際にこの連結リストからchunkを削除し、プログラムがメモリ領域をfreeすると、freeされたchunkが連結リストに加わる。
chunkは連結リストとして管理されているので、各chunkには「次のchunk」を指定するポインタ(Windowsでは「flink」、linuxでは「fd」)や「前のchunk」を指定するポインタ(Windowsでは「blink」、linuxでは「bk」)がある。
未使用chunkと隣接するメモリ領域が解放された場合は、解放されたメモリ領域と未使用chunkとを連結 (coalesce) する事で1つの大きなchunkを作って管理する。
既に述べたように、典型的なスタックベースのオーバーフロー攻撃では、本来データを格納すべき箇所にシェルコードやNOP命令のようなコードを置き、リターンアドレスを書き換えてこれらのコードにジャンプして、これらのコードを実行する必要があった。しかしW ⊕ {\displaystyle \oplus } Xが実装された実行環境ではデータを格納すべき箇所におけるコード実行を不許可としているので、こうしたオーバーフロー攻撃を仕掛ける事はできない。
そこでW ⊕ {\displaystyle \oplus } Xを回避する為に考案されたのがReturn-to-libc攻撃である。この攻撃では、リターンアドレスのジャンプ先をデータ格納箇所に書き換えるのではなく、標準Cライブラリ(libc)のような共有ライブラリ・DLLにジャンプするよう書き換える。こうしたライブラリはデータ格納箇所以外に置かれているので(W ⊕ {\displaystyle \oplus } Xが実装された環境においても)実行許可がある。そこで攻撃者はライブラリ内の関数を悪用して、攻撃を仕掛ける事ができる。
実行環境がASLRを実装していれば、libc等のライブラリの仮想アドレスはランダムに変わるので、攻撃者がジャンプ先をライブラリに落ちるようリターンアドレスを書き換えるのは困難になる。