アール‐オー‐ピー【ROP】
読み方：あーるおーぴー
ROP run of paper,run of press
Return-oriented programming
Return-oriented programming（ROP）は、実行保護やコード署名などのセキュリティ防御の機構が存在するマシンで任意コードの実行を可能にするセキュリティエクスプロイトである[1][2][3]。
この手法では、攻撃者はコールスタックを操作してプログラムの制御フローを乗っ取り、マシンのメモリ上に存在する「ガジェット」と呼ばれる命令群を実行する[4]。各ガジェットは通常return命令で終わり、既存のプログラムまたは共有ライブラリのコードのサブルーチンに存在する。これらのガジェットを組み合わせることで、単純な攻撃を無効化する防御機構が存在するマシンで攻撃者が任意の命令を実行できるようになる。
背景
Return-oriented programmingは、スタックスマッシング攻撃の発展形である。一般にこの種類の攻撃は、攻撃者がバッファオーバーフローなどのプログラムのバグを利用してコールスタックを操作することで可能になる。バッファオーバーフローは、ユーザから受け取ったデータをメモリに保存する際に境界検査を正常に行わない関数が、正しく保存できる量よりも多くのデータを受け取ることで発生する。大きすぎるデータがスタックに書き込まれると、関数の変数に割り当てられた空間（右の図で「Locals」と表示されている部分）をオーバーフローし、returnアドレスを上書きしてしまう場合がある。このアドレスはその後関数が制御フローを呼び出し元に戻すときに参照されるが、これが上書きされた場合、制御フローは新しいreturnアドレスが指定した位置に分岐してしまう。
一般的なバッファオーバーフロー攻撃では、攻撃者は単純に攻撃用のコード（ペイロード）をスタックに書き込み、returnアドレスをこれらの書き込んだ命令の位置に上書きする。1990年代まで、当時一般的に流通していたオペレーティングシステムにはこういった攻撃に対する防御機構が一切なかった。例えば、Microsoft Windowsには、2004年までバッファオーバーフローへの防御機構が存在しなかった[5]。しかし最終的には、オペレーティングシステムは書き換え可能なメモリ空間を実行不可能にする実行保護と呼ばれる仕組みを導入し、バッファオーバーフローバグの利用への対策を実装するようになった。実行保護が有効になっていると、マシンはユーザが書き込み可能な領域のメモリにある命令の実行を拒否するようになるため、攻撃者はスタックにペイロードを書き込み、returnアドレス上書きでペイロードにjumpすることができなくなる。この後、これらの保護を強化するため、ハードウェアサポートも一般に流通するようになった。
データ実行保護により、バッファのメモリ部分は実行不可能とマークされているため、攻撃者はバッファに書き込まれた命令を直接実行することができなくなる。この保護を回避するため、Return-oriented programmingは悪意のある命令を注入するのではなく、returnアドレスを書き換えることで、実行可能なメモリ領域にすでに存在する「ガジェット」と呼ばれる命令群を利用する。攻撃者は悪意のあるコードを直接実行するのではなく、returnアドレスを書き換えることで実行可能とマークされている命令群を組み合わせて実行するため、一般的なデータ実行保護はこのような攻撃に対しては無力である。
return-into-library
現在流通しているデータ実行保護は、前述した従来のバッファオーバーフロー脆弱性をほぼ不可能にし、攻撃者が実行可能とマークされてすでにメモリ上に存在しているプログラムおよび共有ライブラリのコードしか実行できないようにする。libcなどの共有ライブラリは、システムコールを実行するためのサブルーチンやその他の攻撃者にとって有用な関数を含んでいるため、攻撃を組み立てるためのコードを探す上で重要となる。
return-to-library攻撃では、攻撃者は前述の手法でバッファオーバーフロー脆弱性を悪用して制御フローを乗っ取る。ただし、攻撃者はペイロードをスタックに書き込む代わりに、利用可能なライブラリの関数を選んでその最初のアドレスにreturnアドレスを上書きする。残りのスタック位置は、攻撃者が望む動作を実行するため、正しいパラメータを関数に渡すよう呼び出し規約に従って上書きされる。この手法はSolar Designerが1997年に初めて提唱し[6]、後に無限の関数呼び出しのチェーンを可能にするよう拡張された[7]。
borrowed code chunks
x64プロセッサの普及に伴い、バッファオーバーフロー脆弱性を利用したコールスタック操作だけでは任意の引数のライブラリ関数呼び出しを組み立てることができなくなり、関数への最初の引数をスタックではなくレジスタに渡す新しいサブルーチン呼び出し規約に対応する必要が生じてきた。また、共有ライブラリの開発元も、システムコールのラッパー関数など、攻撃者にとって特に有用なライブラリ関数を除去したり、制限したりし始めた。結果、return-into-library攻撃を成功させることは困難になった。
これに対抗して、関数全体ではなく、ライブラリ内の関数の一部を利用して、より単純な攻撃に対する防御を備えたマシン上でバッファオーバーフローの脆弱性を突く攻撃の手法が現れた[8]。この手法は、スタックから値をpopしてレジスタに入力する命令群を含む関数を探索することで、攻撃者が適切な値を正しいレジスタに入れ、新しい呼び出し規約の下で関数呼び出しを実行することを可能にする。攻撃の残りの部分は、通常のreturn-into-library攻撃と同様である。
攻撃
Return-oriented programmingは、先述のborrowed code chunks手法をベースとし、これにループや条件分岐を含むチューリング完全性を付け加えたものである[9][10]。つまり、Return-oriented programmingは攻撃者が危殆化したマシン上で実行できる完全な言語を提供する。Hovav Shachamが2007年にこの手法を公表し[11]、C標準ライブラリにリンクし、悪用可能なバッファオーバーフロー脆弱性を含むアプリケーションに対してReturn-oriented programmingを用いることであらゆるプログラミングの要素が再現可能であることを示した。
Return-oriented programmingは、その有用性や防御機構に対する耐性などの点で他の種類の攻撃よりも優れている。共有ライブラリからの危険な可能性のある関数の除去を含め、前述したいずれのエクスプロイト対策もReturn-oriented programmingに対して有効ではない。
x86
Return-oriented programmingは様々なアーキテクチャ上で実行可能であるが[11]、Shachamの論文および多くのフォローアップ研究はIntel x86アーキテクチャを対象としている。x86アーキテクチャは可変長のCISC命令セットであり、x86におけるReturn-oriented programmingでは、この命令セットが非常に密集している、つまり、あらゆるランダムなバイド列が何らかの正当なx86命令群として解釈される可能性が高いという事実を利用する。
つまり、制御フローを変更するオペコード（特にreturn命令 0xC3）を探索し、その前に存在する有用な命令群を探索するという手法が可能になる。これらの命令ガジェット群は、バッファオーバーフローエクスプロイト経由でreturnアドレスを最初のガジェットの先頭のアドレスに上書きし、以降のガジェットのアドレスをスタックに書き込むことでチェーンできる。最初のガジェットの実行が終了すると、return命令が実行され、2番目のガジェットのアドレスがスタックからpopされ、そのアドレスにjumpする。そのガジェットの実行が終了すると、同様にチェーンは3番目のガジェットに移り、これが繰り返される。小さな命令群をチェーンすることで、攻撃者は既存のライブラリのコードから任意のプログラムの挙動を得ることができる。Shachamは、あらゆる十分に大きいコード（C標準ライブラリを含む）において、チューリング完全性を得るのに十分な量のガジェットが存在すると主張している[11]。
ガジェットの探索とバイナリに対する攻撃の組み立てを支援する自動ツールも開発されている[12]。例えば、ROPgadgetは、バイナリから有用な可能性のあるガジェットを探索し、shellをspawnして攻撃者からの任意の命令を受け取る攻撃用ペイロードの組み立てを試みる。
アドレス空間配置のランダム化
アドレス空間配置のランダム化（ASLR）にも脆弱性は存在する。Shacamら[13]によると、32ビットのアーキテクチャにおけるASLRはアドレスのランダム化に利用可能なビットの数によって制限される。32ビットのうち、16ビットのみがランダム化に利用可能であり、16ビット分のランダム化は数分でブルートフォース攻撃により突破可能である。なお、64ビットのアーキテクチャはより堅固で、64ビット中40ビットがランダム化に利用可能である。40ビット分のランダム化に対するブルートフォース攻撃は可能ではあるが、気づかれない可能性は低い[要出典]。ブルートフォース攻撃に加えて、脱乱択化の手法も存在する。
完全なランダム化が行われている環境においても、何らかのメモリ内容のリークがあれば、ランタイムで共有ライブラリなどの基底アドレスを計算することが可能になる場合がある[14]。
return命令を使わない手法
Checkowayら[15]によると、x86およびARMアーキテクチャでreturn命令（x86では0xC3）を使わずにReturn-oriented programmingを実行することが可能である。Checkowayらの手法では、マシンのメモリにすでに存在する命令群から、return命令と同様の動作をするものを選択する。return命令には2つの動作がある。まず、スタックの最上位にある4バイトの値を探索して命令ポインタをその値に設定し、次にスタックポインタの値を4増やす（pop命令と同様）。x86アーキテクチャでは、jump命令およびpop命令の組み合わせによりreturn命令を実行することができる。ARMでは、load命令およびbranch命令の組み合わせにより同様のことが行える。
この新しい手法はreturn命令を使わないため、防御がより難しくなる。ただし、防御プログラムがreturn命令だけでなくjump命令も探索する場合、この攻撃は検出されうる。
防御
G-Free
G-Freeは、Kaan Onarlioglu、Leyla Bilge、Andrea Lanzi、Davide Balzarotti、Engin Kirdaが考案した手法であり、あらゆる形態のReturn-oriented programmingに対する実用的な防御法である。G-Freeは、実行可能バイナリ内の分岐命令（攻撃者が制御フローを変更するのに利用可能なreturn命令やcall命令）をすべて除去し、分岐命令が攻撃者に利用されるのを防ぐ。G-Freeがreturnアドレスを保護する仕組みは、StackGuardのRandom XORカナリアと類似している。また、バリデーションブロックを追加して関数呼び出しの真正性を確認し、予期される値が見つからない場合はアプリケーションをクラッシュさせる[16]。
アドレス空間配置のランダム化
Return-oriented programmingをベースにした攻撃を防ぐため、多くの手法が提案されてきた[17]。それらの多くは、プログラムおよびライブラリコードの位置をランダム化し、ガジェットとして利用可能な命令の位置を攻撃者が正確に予測できないようにすることで、Return-oriented programmingのチェーンを作成できないようにするものである。この手法の実装として一般的なアドレス空間配置のランダム化（ASLR）は、プログラムの読み込み時に毎回共有ライブラリをメモリ上の別の場所に読み込む。この手法は最近の主要なオペレーティングシステムの多くで実装されているが、ASLRはinformation leakage攻撃やその他のメモリ上の既知のライブラリの関数の位置を特定する手法に対して脆弱である。もし攻撃者が既知の命令の位置を1つ見つけるのに成功すると、その他すべての命令の位置も推測でき、Return-oriented programming攻撃を組み立てることができるからである。
さらに一歩進んで、ライブラリの位置だけでなくあらゆる命令およびその他のプログラムの状態（レジスタやスタックオブジェクト）の位置を変更することもできる[18][19][20]。ただし、ランタイムでランダム化された命令を元に戻すため、software dynamic translatorなどの高度なランタイムサポートが必要であり、ガジェットの発見および利用を難しくする一方で、大きなオーバーヘッドが伴う。
kBouncerの手法では、オペレーティングシステムを修正し、return命令が実際にcall命令の直後の位置に制御フローを戻しているかどうかを確認する。これにより、ガジェットのチェーン化は防がれるが、大きなパフォーマンス上の負担があるほか[要説明]、return命令ではなくjump命令やその他の制御フローを変更する命令を書き換えるJump-oriented programmingに対しては有効ではない[21]。
SEHOP
Structured Exception Handler Overwrite Protection（SEHOP）は、システムを一般的なオーバーフロー攻撃（特に構造化例外処理に対する攻撃）から保護するWindowsの機能である。
関連項目
参考文献
- ^ “Check Point Secure Platform Hack” (英語). Pentest. Barcelona, Spain: Pentest Consultores. pp. 219 (2007年10月1日). 2023年1月6日閲覧。
- ^ “Thread: CheckPoint Secure Platform Multiple Buffer Overflows”. The Check Point User Group. 2021年4月17日時点のオリジナルよりアーカイブ。2023年1月6日閲覧。
- ^ “Return-Oriented Programming: Exploits Without Code Injection”. 2009年8月12日閲覧。
- ^ “When Good Instructions Go Bad: Generalizing Return-Oriented Programming to RISC”. Proceedings of the 15th ACM conference on Computer and communications security - CCS '08. (October 2008). pp. 27–38. doi:10.1145/1455770.1455776. ISBN 978-1-59593-810-7
- ^ Microsoft Windows XP SP2 Data Execution Prevention
- ^ Solar Designer, Return-into-lib(c) exploits, Bugtraq
- ^ Nergal, Phrack 58 Article 4, return-into-lib(c) exploits
- ^ Sebastian Krahmer, x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique, September 28, 2005
- ^ Abadi, M. N.; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (November 2005). “Control-Flow Integrity: Principles, Implementations, and Applications”. Proceedings of the 12th ACM conference on Computer and communications security - CCS '05. pp. 340–353. doi:10.1145/1102120.1102165. ISBN 1-59593-226-7
- ^ Abadi, M. N.; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (October 2009). “Control-flow integrity principles, implementations, and applications”. ACM Transactions on Information and System Security 13: 1–40. doi:10.1145/1609956.1609960.
- ^ a b c Shacham, H. (October 2007). “The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)”. Proceedings of the 14th ACM conference on Computer and communications security - CCS '07. pp. 552–561. doi:10.1145/1315245.1315313. ISBN 978-1-59593-703-2
- ^ Jonathan Salwan and Allan Wirth, ROPgadget - Gadgets finder and auto-roper
- ^ [Shacham et al., 2004] Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, and Dan Boneh. On the effectiveness of address-space randomization. In Proceedings of the 11th ACM conference on Computer and Communications Security (CCS), 2004.
- ^ [Bennett et al., 2013] James Bennett, Yichong Lin, and Thoufique Haq. The Number of the Beast, 2013. https://www.fireeye.com/blog/threat-research/2013/02/the-number-of-the-beast.html
- ^ CHECKOWAY, S., DAVI, L., DMITRIENKO, A., SADEGHI, A.-R., SHACHAM, H., AND WINANDY, M. 2010. Return-oriented programming without returns. In Proceedings of CCS 2010, A. Keromytis and V. Shmatikov, Eds. ACM Press, 559–72
- ^ ONARLIOGLU, K., BILGE, L., LANZI, A., BALZAROTTI, D., AND KIRDA, E. 2010. G-Free: Defeating return-oriented programming through gadget-less binaries. In Proceedings of ACSAC 2010, M. Franz and J. McDermott, Eds. ACM Press, 49–58.
- ^ Skowyra, R.; Casteel, K.; Okhravi, H.; Zeldovich, N.; Streilein, W. (October 2013). “Systematic Analysis of Defenses against Return-Oriented Programming”. Research in Attacks, Intrusions, and Defenses. Lecture Notes in Computer Science. 8145. pp. 82–102. doi:10.1007/978-3-642-41284-4_5. ISBN 978-3-642-41283-7. オリジナルの2014-02-22時点におけるアーカイブ。
- ^ Venkat, Ashish; Shamasunder, Sriskanda; Shacham, Hovav; Tullsen, Dean M. (2016-01-01). “HIPStR: Heterogeneous-ISA Program State Relocation”. Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems. ASPLOS '16 (New York, NY, USA: ACM): 727–741. doi:10.1145/2872362.2872408. ISBN 9781450340915.
- ^ Hiser, J.; Nguyen-Tuong, A.; Co, M.; Hall, M.; Davidson, J. W. (May 2012). “ILR: Where'd My Gadgets Go?”. 2012 IEEE Symposium on Security and Privacy. pp. 571–585. doi:10.1109/SP.2012.39. ISBN 978-1-4673-1244-8
- ^ US 9135435, Venkat, Ashish; Arvind Krishnaswamy & Koichi Yamada et al., "Binary translator driven program state relocation", published 2015-09-15, assigned to Intel Corp.
- ^ Vasilis Pappas. kBouncer: Efficient and Transparent ROP Mitigation. April 2012.
外部リンク
- ROPのページへのリンク
