Data Execution Protectionに関する考察

Windows XP SP2で追加される機能の一つにData Execution Protection(DEP)がある。昨日、この機能の解説記事を読んでみた。

DEPとは、簡単に言うとデータ領域上でのコード実行を防ぐ技術である。悪意のあるコードの多くはコードをデータ領域に送り込みアプリケーションのバグをついてこのコードの実行を試みる。
したがって、データ領域上のコードの実行が禁止されると攻撃者は、上記の方法で任意のコードを実行するこができない。アプリケーションのバッファ操作コードのミスに起因する攻撃の多くはこの機能で防げるわけである。

そうすると次に問題となってくるのは、この技術が既存のアプリケーションに対してどの程度の互換性を確保しているのかということである。結論としては、実行時にコード生成するアプリケーション(JITとか)、メモリ周りのドライバーで不具合がでる可能性がある。
ドライバーの問題については、特殊な環境でない限りは問題は起こらないだろう。問題なのは、JITのようなアプリケーションである。つまり、Javaや.NETが動かなくなる可能性があるということだ。さすがにそこら辺が動かないとクレーム殺到するわけで、MSもそこまでアフォではなくきちんと逃げ道を用意している。SP2を32-bit版Windowsにインストールするとデフォルトでは、stackに対するDEPのみが有効になり、heapに対してはオフになる。従って、Javaや.NETがstackにコード生成して実行するという危篤なことをやっていない限りは通常通り動作する。
heapに対するDEPはJITの開発者がDEP対応するのを待ってという感じなのでしょう。つまり、sp2が普及してもまだしばらくはheapを狙った攻撃は可能ってことですな。JITに引きづられてるって感じがしてならないけど、ここら辺が妥協ラインなんでしょうな。

DEPというテクノロジーの根底には、「実行コードはOSによってメモリにロードされる」というポリシーがあるように思える。このポリシーに従うとすると、JITはアプリケーションが実行コードをメモリにロードしているので例外として扱われなければならない。で、実行可能領域を確保するためにVirtualAlloc()がAPIに追加されている。このAPIは、PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_WRITECOPYのいずれかの属性を指定でき、この属性はあとから変更することも可能。実行コード生成時に攻撃されるリスクを軽減するため、実行コード生成後はPAGE_EXECUTE属性に設定して書き込み可能な時間をできるだけ短くすることが重要。

JITは動かなくなるようだけど、DEPで多くの攻撃は防がれるようになるのかなと少し期待。普及には時間かかるんでしょうけど。VirtualAlloc()に関しては、実行コード生成をするアプリケーションってのがユーザーレベルで走るべきなのか微妙な立場にいることを考えるとうまい妥協ラインだったんじゃないかという気がする。