RECONシリーズの最終回は、情報セキュリティ業界でもっともホットな攻撃方法であるReturn Oriented Programming(ROP)を紹介したい。第38回で少しだけ紹介したROPは、OSに組み込まれている情報セキュリティ対策機構を回避するために使用されるテクニックである。

Dino Dai Zovi氏の発表「Mac OS X return oriented exploitation(スライドはこちら)」は、Mac OS XにおけるROPを使用した攻撃法のプレゼンテーションであった。ROPはスタック保護やDEP、ASLRといったOSに備わっている情報セキュリティ対策機構の向上をうけて編み出された攻撃方法のひとつである。

OSに備わっている情報セキュリティ対策機構の向上(出典:「Dino Dai Zobi, "Mac OS X return oriented exploitation" 」

この図のようなOSに備わっている情報セキュリティ対策機構の向上により、シェルコードを直接的に実行させるような攻撃は成功することがほぼなくなった。従来であれば、スタック上に配置されたシェルコードをシンプルに実行させることが一般的であったが、この方法が通用しなくなったのである。

また、データ領域からの実行保護に対してはReturn-into-libcがその迂回策として使用できたが、ASLRによる各種のメモリ領域の無作為化により、これも困難となった。バッファオーバーフローなどのメモリを上書きするタイプの攻撃は「特定のアドレスが固定である」ことに依存するためである。

ROPはこれらの課題を解消するための一手段である。ROPはReturn-into-libc と同様に、アセンブラで2命令程度の短いコードブロックをたくさん組み合わせることで、シェルコードの代替として実行する手法である。

Return Oriented Programmingの例。任意のアドレスに4バイトの値を書き込むコードを示している(出典:「Dino Dai Zobi, "Mac OS X return oriented exploitation"」)

シェルコードの代替コードブロック自体は、メモリ上に展開されたDLLや実行イメージの一部を使用するのである。したがって当然ALSRの制限を受けることになるが、攻撃を成功させる要素も残っている。それは次のようなものだ。

1. ALSRによってアドレスが無作為化されないDLLがある場合は、そのDLLのコードはROPに使用できる
2. すべて無作為化されている場合は、メモリリークやベースアドレスを参照できる脆弱性と併用することが条件となる

本連載の第38回で紹介したAdobe Readerを狙った攻撃コードでは、1の条件があてはまっていた。つまり、Windows XP SP3上のAdobe Readerで使用されるDLLファイル(BIB.dll)が必ずある特定のアドレスにロードされることを悪用していたのだ。逆をいえば、ASLRが有効になっているPCではこの攻撃は失敗する。では、Mac OS Xではどうなのか?

Mac OS Xにおいても、次のような情報セキュリティ機構が組み込まれている。

• Mac OS Xでは、スタック領域にはNXビットがセットされており、そのままコード実行には悪用できない(ただし、ヒープ領域には適用されていない)
• ダイナミックライブラリがロードされるアドレスは、ソフトウェアがインストールされるタイミングで変化する

若干保護機構が弱いようにも感じられるが、ある程度の保護機構が実装されているようだ。ただし、Mac OS Xにおいても、特定のアドレスに必ずロードされるライブラリが存在している。それはダイナミックリンカ(dyld)である。また、__IMPORTセクションという読み書き実行可能(RWX)な領域もあり、シェルコードを書き込むには絶好の書き込み先候補となる。

このような特性をそのまま悪用することで、ROPを使用した攻撃は可能であると、Dino Dai Zovi氏は述べた。また対策としては、64bit版のOS Xを使用することを推奨していた。その理由は、64bit版のMac OS XではヒープもNXビットがセットされている。また関数呼び出しのパラメータがレジスタにセットされるようになっているため、パラメータのスタック渡しが前提で、かつスタックのデータをち密に操るROPが通用しない。また__IMPORTセクションの属性も変更されている。とはいえ、完全に64bit動作するアプリケーションが少ないのもまた事実であるという。Mac OS Xを狙う攻撃に直面することは現在のところWindowsと比較して少ないが、このような特性を知っておくことは重要であろう。