ハードウェアDEPでも防げないコード実行型脆弱性を防ぐ方法

去年から猛威をふるっているGumblerは、ユーザーがWebサイトを閲覧しただけで、アプリケーションに含まれる脆弱性を突かれ、感染するウイルスだ。

このGumblerは異なる攻撃方法を実装した亜種が大量にあることで、現在主流となっているパターンマッチング型ウイルス対策ソフトでは防御しにくくなっている。パターンが更新されるたびに新たな亜種が出現し、いたちごっことなっている。

パターンマッチングをすり抜けたウイルスは脆弱性を突いてユーザーに感染するのだが、突かれた脆弱性によるコードの実行を防ぐ機能がWindows XPSP2以降に搭載されている。いわゆるハードウェアDEP（Data Execute Prevention）だ。

ハードウェアDEPは、データ領域でのコード実行を強制的に遮断する機能だ。このため、「バッファオーバーフロー」をはじめとしたあらゆるコード実行型脆弱性に有効な対策であると考えられている。

そのため、DEPを有効にすることで、Gumblarがコードを実行させることが不可能となり、防御力を高めることが可能となる。しかしながら、中国のハッカーがグーグルのネットワーク侵入に使ったAurora攻撃のように、現在のハードウェアDEPでは、対策が困難な事例が現れはじめている。

現在のハードウェアDEPの技術的な問題点とその対応策について、フォーティーンフォティ技術研究所の奥天陽司氏に話を伺った。

─ハードウェアDEPの問題点

ハードウェアDEPの基本的な考え方は、プロセッサがサポートしているNX/XDビットを利用して、コード実行可能なメモリ領域とコード実行不可能なメモリ領域を明確に分離します。そして、これを利用して、意図しないコード実行を防止するというものです。

メモリ破壊により発生する脆弱性は、一般的に、

(1)脆弱性を利用した制御フローの奪取
(2)スタック領域・ヒープ領域に読み込まれた攻撃コードの実行

の2つのステップから成り立ちます。

ハードウェアDEPが有効化された環境下では、プログラムが明示的に実行可能とマークしない限り、スタック領域・ヒープ領域はコード実行不可能となり、前述の(2)を防止することができます。

これは、攻撃者から見ると「脆弱性を攻撃して制御は奪えたものの、意味のある悪事がなにもできない（※）」という状況です。

※プロセスのクラッシュによる DoS攻撃は例外

─Return-into-libc攻撃によりハードウェアDEPをバイパス

　しかしハードウェアDEPは、Return-into-libc攻撃と呼ばれる手法で簡単にバイパスできてしまう問題があり、攻撃方法が公表されています。

　Return-into-libc攻撃とは、例えばスタックベースのバッファオーバーフローにおいて、親関数に戻る際に攻撃コード（shellcode）にジャンプするのではなく、何らかのAPIに直接ジャンプさせることにより、データ領域でのコード実行を行うことなく攻撃を成功させる手法です。

　これらのAPIはそもそも実行すべきものであるため、そのメモリ領域は元からコード実行可能とマークされています。このため、以下のような攻撃手法で攻撃コードを実行することができます。

(1)脆弱性を利用して制御フローを奪取する
(2)Return-into-libcによりメモリ属性を変更するAPIを呼び出し、スタック領域・ヒープ領域などデータ領域をコード実行可能にマークする
(3)データ領域に置かれた攻撃コードを実行する

　これにより、ハードウェアDEPの基本コンセプトである「データ領域でのコード実行防止」を迂回した攻撃が成立します。近年の脆弱性攻撃は、このReturn-into-libc攻撃によりハードウェアDEPをバイパスするものが多く、もはや脆弱性攻撃の標準手法となりつつあります。

─ハードウェアDEPとASLRも回避される新攻撃が急増

　しかし、このReturn-into-libc攻撃は、APIのエントリアドレスを直接指定する必要があったため、攻撃安定性に少々難がありました。また、Windows Vista以降に搭載されたASLR(Address Space Layout Randomization)を組み合わせる事により、攻撃安定度を大きく低下させる事が可能となりました。しかし、ASLRを利用するためにはソフトウェアベンダが、ASLRが有効になるように製品をビルド・出荷する必要があり、マイクロソフト社を除く多くのサードパーティベンダの製品では、ASLRが有効に利用されていないのが現状です。そのため、こうしたASLRの対象外となっているサードパーティ製品のDLLを利用することで、安定的に攻撃を成功させることが可能です。

─Return-into-libc攻撃は検知可能

このようにハードウェアDEPとASLRの組み合わせだけでは、対策とはいえない現状となっています。

ハードウェアベースの機能では原理的に複雑な機能を提供することは難しいのですが、ソフトウェアで実現することにより、プロセスの状態やDLLの関係性など細かいチェックが可能となります。

このため、Return-into-libc攻撃のような、ハードウェアDEPでは防御しきれない、ほとんどのコード実行型脆弱性攻撃を防御することが可能です。

このようなコンセプトで開発したのが「yarai 脆弱性攻撃防御機能」です。このエンジンでは、データ領域でのコード実行を監視する機能をソフトウェアで実現しています。

それだけでなく、「yarai 脆弱性攻撃防御機能」は、「任意のコードを実行できる」といったタイプの「コード実行型脆弱性」に対する攻撃をパターンに依存することなく、汎用的に防御する機能を提供します。

コード実行型脆弱性の代表である「バッファオーバーフロー」をはじめ、「フォーマットストリング脆弱性」や「関数ポインタ書き換え」、「ダブルフリー」といった、さまざまな致命的な問題を引き起こす可能性がある脆弱性を防御することができます。

また、近年の高度な攻撃に加え、最近多発している「パッチが提供されていない状態での攻撃（0-day）」に対しても有効に機能し、機知・未知の脆弱性攻撃の脅威を大幅に軽減することが可能となるでしょう。

・新製品「yarai 脆弱性攻撃防御機能」

このようにReturn-into-libc攻撃を防御可能なだけでなく、さまざまなコード実行型の脆弱性を防御可能な「yarai 脆弱性攻撃防御機能」はフォーティーンフォティ技術研究所から、6月に発売が予定されている。

「yarai 脆弱性攻撃防御機能」は、実行中のプログラムやOSを監視し、コード実行型脆弱性攻撃を検知し、攻撃コード(shellcode)の実行を検知すると、アラートを上げプログラムの実行を停止するというソフトウェアだ。

既存のパターンマッチ型ウィルス検知ソフトでは防ぎきれない、バッファオーバーフローなどを突いた攻撃を防御する助けとなるだろう。もちろん、既存の他社製パターンマッチング型ウイルス対策ソフトと併用も考えられており、同時に実行した場合もお互いの動作に悪影響を与えることは全くないという。

1ライセンス3600円からと安価なため、経済的な負担は最小限に、クライアントのマルウェア感染によるリスクを減らす効果が期待できるだろう。

ただし残念なことに対応するOSは32ビット版に限られている。64ビット版には今後対応していくということだ。今後の対応に期待したい。

株式会社フォティーンフォティ技術研究所
yarai 脆弱性攻撃防御機能
http://www.fourteenforty.jp/products/yaraizdp/