リターン指向プログラミング

リターン指向プログラミング（ROP）は、実行可能空間保護やコード署名などのセキュリティ防御^[1]^[2]が存在する場合でも攻撃者がコードを実行できるようにするコンピュータセキュリティの悪用手法である。^[3]

この手法では、攻撃者はコールスタックの制御権を獲得してプログラム制御フローを乗っ取り、次に「ガジェット」と呼ばれる、マシンのメモリにすでに存在する慎重に選択されたマシン命令シーケンスを実行します。 ^[4]^{[注 1]}各ガジェットは通常、戻り命令で終了し、既存のプログラムや共有ライブラリコード内のサブルーチンに配置されます。 ^{[注 1]}これらのガジェットを連鎖させることで、攻撃者は、より単純な攻撃を阻止する防御を採用したマシン上で任意の操作を実行できます。

背景

リターン指向プログラミングは、スタックスマッシング攻撃の高度なバージョンです。通常、この種の攻撃は、攻撃者がプログラムのバグ(多くの場合、バッファオーバーラン)を利用してコールスタックを操作するときに発生します。バッファオーバーランでは、ユーザー提供のデータをメモリに格納する前に適切な境界チェックを実行しない関数は、適切に格納できる量を超える入力データを受け入れます。データがスタックに書き込まれている場合、余分なデータによって関数の変数 (たとえば、右側のスタック図の「ローカル」) に割り当てられた領域がオーバーフローし、戻りアドレスが上書きされる可能性があります。このアドレスは、後で関数によって制御フローを呼び出し元にリダイレクトするために使用されます。上書きされている場合、制御フローは新しい戻りアドレスで指定された場所に転送されます。

標準的なバッファオーバーラン攻撃では、攻撃者はスタックに攻撃コード (「ペイロード」) を書き込み、戻りアドレスをこれらの新しく書き込まれた命令の場所で上書きします。1990 年代後半まで、主要なオペレーティングシステムではこれらの攻撃に対する保護が提供されていませんでした。Microsoft Windows は2004 年までバッファオーバーラン保護を提供しませんでした。 ^[5]最終的に、オペレーティングシステムは、データが書き込まれるメモリを実行不可としてマークすることで、バッファオーバーフローバグの悪用に対抗するようになりました。この手法は、実行可能空間保護と呼ばれます。これを有効にすると、マシンはメモリのユーザー書き込み可能領域にあるコードの実行を拒否し、攻撃者がスタックにペイロードを配置して戻りアドレスの上書きによってそこにジャンプするのを防ぎます。後に、この保護を強化するハードウェアサポートが利用可能になりました。

データ実行防止機能を使用すると、バッファのメモリセクションが非実行可能としてマークされるため、攻撃者はバッファに書き込まれた命令を直接実行できません。この保護を無効にするために、リターン指向プログラミング攻撃では、悪意のある命令を挿入するのではなく、戻りアドレスを操作することで、実行可能メモリにすでに存在する「ガジェット」と呼ばれる命令シーケンスを使用します。一般的なデータ実行防止実装では、この攻撃を防御できません。これは、攻撃者が悪意のあるコードを直接実行するのではなく、格納されている戻りアドレスを変更することで「正常な」命令シーケンスを組み合わせたためです。したがって、使用されたコードは実行可能としてマークされます。

図書館への返却技術

データ実行防止の広範な実装により、従来のバッファオーバーフローの脆弱性を上記の方法で悪用することは困難または不可能になりました。代わりに、攻撃者は、プログラムコード自体やリンクされた共有ライブラリなど、メモリ内にすでに実行可能としてマークされているコードに制限されました。libcなどの共有ライブラリには、システムコールを実行するためのサブルーチンや、攻撃者にとって潜在的に有用なその他の機能が含まれていることが多いため、攻撃を組み立てるためのコードが見つかる可能性が最も高くなります。

ライブラリへのリターン攻撃では、攻撃者は、上で説明したように、バッファオーバーランの脆弱性を悪用してプログラム制御フローを乗っ取ります。攻撃者は、スタックに攻撃ペイロードを書き込む代わりに、利用可能なライブラリ関数を選択し、戻りアドレスをそのエントリ位置で上書きします。その後、適用可能な呼び出し規約に従って、スタック位置をさらに上書きし、適切なパラメータを関数に慎重に渡して、攻撃者にとって有用な機能を実行できるようにします。この手法は、1997 年にSolar Designerによって初めて発表され、 ^[6]後に関数呼び出しの無制限の連鎖に拡張されました。^[7]

借用したコードチャンク

64 ビット x86プロセッサの登場により、サブルーチン呼び出し規約が変更され、関数の最初のいくつかの引数をスタックではなくレジスタで渡す必要が生じました。これにより、攻撃者は、バッファオーバーランのエクスプロイトを介して呼び出しスタックを操作するだけで、必要な引数を持つライブラリ関数呼び出しを設定できなくなりました。共有ライブラリの開発者も、システムコールラッパーなど、攻撃者にとって特に便利なアクションを実行するライブラリ関数を削除または制限し始めました。その結果、return-into-library 攻撃を成功させることがはるかに困難になりました。

次の進化は、関数全体ではなくライブラリ関数のチャンクを使用して、より単純な攻撃に対する防御を備えたマシンのバッファオーバーランの脆弱性を悪用する攻撃の形で現れました。^[8]この手法は、スタックからレジスタに値をポップする命令シーケンスを含む関数を探します。これらのコードシーケンスを慎重に選択することで、攻撃者は適切な値を適切なレジスタに配置し、新しい呼び出し規約に基づいて関数呼び出しを実行できます。攻撃の残りの部分は、ライブラリへの戻り攻撃として進行します。

攻撃

リターン指向プログラミングは、借用コードチャンクアプローチを基盤とし、ループや条件分岐を含むチューリング完全な機能を攻撃者に提供するように拡張します。^[9]^[10]言い換えれば、リターン指向プログラミングは、攻撃者が侵入したマシンに任意の操作を実行させるために使用できる、完全に機能する「言語」を提供します。Hovav Shacham は2007 年にこの手法を公開し^[11]、C 標準ライブラリにリンクされ、悪用可能なバッファオーバーランの脆弱性を含むターゲットアプリケーションに対して、リターン指向プログラミングを使用してすべての重要なプログラミング構造をシミュレートする方法を示しました。

リターン指向プログラミング攻撃は、表現力と防御手段に対する耐性の両方において、これまでに説明した他の種類の攻撃よりも優れています。共有ライブラリから潜在的に危険な関数を完全に削除するなど、上記のカウンターエクスプロイト手法はどれも、リターン指向プログラミング攻撃に対しては効果的ではありません。

x86アーキテクチャの場合

リターン指向プログラミング攻撃はさまざまなアーキテクチャで実行できますが、^[11] Shacham の論文とその後の研究の大部分は Intel x86アーキテクチャに焦点を当てています。x86 アーキテクチャは可変長CISC命令セットです。x86 でのリターン指向プログラミングは、命令セットが非常に「密」であるという事実、つまり、任意のランダムなバイトシーケンスが x86 命令の有効なセットとして解釈できる可能性が高いという事実を利用します。

したがって、制御フローを変更するオペコード、特に戻り命令 (0xC3)を検索し、バイナリを逆方向に調べて、おそらく有用な命令を形成する先行バイトを探すことができます。これらの命令「ガジェット」のセットは、バッファオーバーランエクスプロイトを介して戻りアドレスを最初のガジェットの最初の命令のアドレスで上書きすることで連鎖できます。その後、後続のガジェットの最初のアドレスがスタックに連続して書き込まれます。最初のガジェットの終了時に、戻り命令が実行され、次のガジェットのアドレスがスタックからポップされ、そこにジャンプします。そのガジェットの終了時に、チェーンは 3 番目のガジェットに続き、以下同様に続きます。小さな命令シーケンスを連鎖させることで、攻撃者は既存のライブラリコードから任意のプログラム動作を作成できます。Shacham は、十分な量のコード (C 標準ライブラリを含むが、これに限定されない) があれば、チューリング完全な機能に十分なガジェットが存在すると主張しています。^[11]

ガジェットの検索とバイナリに対する攻撃の構築のプロセスを自動化する自動化ツールが開発されました。^[12] ROPgadgetと呼ばれるこのツールは、バイナリを検索して潜在的に有用なガジェットを探し、それらを攻撃ペイロードに組み立てて、攻撃者からの任意のコマンドを受け入れるためのシェルを生成します。

アドレス空間レイアウトのランダム化について

アドレス空間レイアウトのランダム化にも脆弱性があります。Shacham らの論文^[13]によると、 32 ビットアーキテクチャ上の ASLR は、アドレスのランダム化に使用できるビット数によって制限されます。32 アドレスビットのうち 16 ビットのみがランダム化に使用でき、16 ビットのアドレスランダム化はブルートフォース攻撃によって数分で破ることができます。64 ビットアーキテクチャはより堅牢で、64 ビットのうち 40 ビットがランダム化に使用できます。40 ビットのランダム化に対するブルートフォース攻撃は可能ですが、気付かれない可能性は低いです。^[要出典]ブルートフォース攻撃に加えて、ランダム化を削除する手法も存在します。

完全なランダム化を行ったとしても、メモリ内容の情報漏洩があった場合、実行時に共有ライブラリなどのベースアドレスを計算することが役に立つだろう。 ^[14]

戻り命令を使用しない場合

Checkoway らの論文^[15]によると、 x86 および ARM アーキテクチャでは、リターン命令 (x86 では 0xC3) を使用せずにリターン指向プログラミングを実行できます。代わりに、マシンのメモリにすでに存在する、リターン命令のように動作するように注意深く作成された命令シーケンスを使用しました。リターン命令には 2 つの効果があります。1 つ目は、スタックの先頭にある 4 バイトの値を読み取り、命令ポインタをその値に設定すること、2 つ目は、スタックポインタ値を 4 増加させることです (ポップ操作に相当)。x86 アーキテクチャでは、jmp 命令と pop 命令のシーケンスがリターン命令として機能します。ARM では、ロード命令と分岐命令のシーケンスがリターン命令として機能します。

この新しいアプローチでは return 命令を使用しないため、防御にはマイナスの影響があります。防御プログラムが複数の return だけでなく、複数の jump 命令もチェックする場合、この攻撃が検出される可能性があります。

防御

Gフリー

G-Free 技術は、Kaan Onarlioglu、Leyla Bilge、Andrea Lanzi、Davide Balzarotti、Engin Kirda によって開発されました。これは、あらゆる形式のリターン指向プログラミングに対する実用的なソリューションです。このソリューションは、バイナリ実行ファイル内のアラインされていないフリーブランチ命令 (攻撃者が制御フローを変更するために使用できる RET や CALL などの命令) をすべて排除し、フリーブランチ命令が攻撃者によって使用されるのを防ぎます。G-Free が戻りアドレスを保護する方法は、 StackGuard によって実装されたXOR カナリアに似ています。さらに、検証ブロックを追加することで関数呼び出しの信頼性をチェックします。期待される結果が見つからない場合、G-Free はアプリケーションをクラッシュさせます。^[16]

アドレス空間レイアウトのランダム化

リターン指向プログラミングに基づく攻撃を阻止するための手法は数多く提案されている。^[17]大半はプログラムとライブラリコードの位置をランダム化することで、攻撃者がガジェットで役立つ可能性のある命令の位置を正確に予測できず、リターン指向プログラミング攻撃チェーンを成功させることができないようにしている。この手法のかなり一般的な実装の 1 つであるアドレス空間レイアウトランダム化(ASLR) では、プログラムのロードごとに共有ライブラリを異なるメモリ位置にロードする。ASLR は最新のオペレーティングシステムで広く導入されているが、情報漏洩攻撃や、メモリ内の既知のライブラリ関数のアドレスを特定するその他の手法に対して脆弱である。攻撃者が 1 つの既知の命令の位置をうまく特定できれば、他のすべての命令の位置を推測し、リターン指向プログラミング攻撃を構築することができる。

このランダム化アプローチは、ライブラリの場所だけでなく、プログラムのすべての命令と/またはその他のプログラム状態（レジスタとスタックオブジェクト）を個別に再配置することでさらに進めることができます。^[18]^[19]^[20]これには、実行時にランダム化された命令を再び組み立てるためのソフトウェア動的トランスレータなどの広範なランタイムサポートが必要です。この手法は、ガジェットを見つけて使用することを困難にするのに効果的ですが、かなりのオーバーヘッドが伴います。

kBouncer が採用した別のアプローチでは、オペレーティングシステムを変更して、戻り命令が実際に制御フローを呼び出し命令の直後の場所にリダイレクトすることを確認する。これによりガジェットの連鎖は防止されるが、パフォーマンスに大きなペナルティが伴い^{[説明が必要]}、戻り命令の代わりにジャンプ命令やその他の制御フロー変更命令を変更するジャンプ指向プログラミング攻撃に対しては効果的ではない。^[21]

バイナリコードのランダム化

Cloud Lambda (FaaS) や IoT リモートアップデートなどの最新システムの中には、クラウドインフラストラクチャを使用してソフトウェアを展開する前にオンザフライでコンパイルを実行するものがあります。実行中のソフトウェアプログラムの各インスタンスにバリエーションを導入する手法により、ROP 攻撃に対するソフトウェアの耐性を大幅に高めることができます。Cloud Lambda をブルートフォースすると、ランダム化されたソフトウェアの複数のインスタンスが攻撃される可能性があり、攻撃の有効性が低下します。Asaf Shelly は 2017 年にこの手法を公開し^[22]、ソフトウェア更新システムでのバイナリランダム化の使用を実証しました。更新されたデバイスごとに、クラウドベースのサービスがコードにバリエーションを導入し、オンラインコンパイルを実行し、バイナリをディスパッチしました。ROP 攻撃はソフトウェアの内部構造に関する知識に依存するため、この手法は非常に効果的です。この手法の欠点は、ランダム化されたソフトウェアのすべてのバリエーションをテストすることは現実的ではないため、展開前にソフトウェアが完全にテストされないことです。つまり、多くのバイナリランダム化手法はネットワークインターフェイスとシステムプログラミングに適用でき、複雑なアルゴリズムにはあまり推奨されません。

セホップ

構造化例外ハンドラーの上書き保護は、最も一般的なスタックオーバーフロー攻撃、特に構造化例外ハンドラーへの攻撃から保護する Windows の機能です。

制御フロー攻撃に対する対策

モノのインターネットの拡大により小型の組み込みシステムが急増するにつれ、そのような組み込みシステムの保護の必要性も高まっています。ハードウェアに実装された命令ベースのメモリアクセス制御（IB-MAC）を使用すると、低コストの組み込みシステムを悪意のある制御フロー攻撃やスタックオーバーフロー攻撃から保護することができます。保護は、データスタックとリターンスタックを分離することで提供できます。ただし、一部の組み込みシステムにはメモリ管理ユニットがないため、ハードウェアソリューションをすべての組み込みシステムに適用することはできません。^[23]

リターン指向ルートキットに対する対策

2010 年に Jinku Li らは、適切に修正されたコンパイラーが各を命令シーケンスに、各を命令シーケンスに置き換えることで、戻り値指向の「ガジェット」を排除できることを提案しました^[24] 。ここで、はプログラム内のすべての「正当な」戻りアドレスの不変の表を表し、はそのテーブルへの特定のインデックスを表します。^[24]^{: 5–6}これにより、関数の最後から別の関数の途中の任意のアドレスに直接戻る戻り値指向のガジェットの作成が防止されます。代わりに、ガジェットは「正当な」戻りアドレスにのみ戻ることができるため、有用なガジェットを作成する難しさが大幅に増加します。 Li らは、「私たちの戻り値間接参照手法は、戻り値指向プログラミングを本質的に、return-into-libc の古いスタイルに逆一般化します」と主張しました。^[24]彼らの概念実証コンパイラには、「オペコードまたは即値オペランドにリターンオペコードが含まれている特定のマシン命令」[24] を処理するためのピープホール最適化フェーズが含まれてい^ました。call fpushl $index; jmp fretpopl %reg; jmp table(%reg)tableindexmovl $0xC3, %eax

ポインタ認証コード (PAC)

ARMv8.3-Aアーキテクチャは、ハードウェアレベルで、ポインタアドレス空間の未使用ビットを利用して、特別に設計された調整可能なブロック暗号^[25]^[26]を使用してポインタアドレスに暗号署名する新しい機能を導入します。この暗号は、必要な値（通常は戻りアドレス）と「ローカルコンテキスト」値（スタックポインタなど）を組み合わせて署名します。

機密性の高い操作 (保存されたポインターに戻るなど) を実行する前に、署名をチェックして、改ざんや不適切なコンテキストでの使用 (エクスプロイトのトランポリンコンテキストから保存された戻りアドレスを利用するなど) を検出できます。

特にiPhoneに使用されているApple A12チップはARMv8.3にアップグレードされ、PACを使用しています。Linuxは2020年にリリースされたバージョン5.7でカーネル内でのポインタ認証のサポートを獲得し、ユーザー空間アプリケーションのサポートは2018年に追加されました。 ^[27]

2022年、MITの研究者らはPACMANと呼ばれるPACに対するサイドチャネル攻撃を公開した。^[28]

ブランチターゲット識別 (BTI)

ARMv8.5-A アーキテクチャでは、ハードウェアレベルで、分岐命令の有効なターゲットを明示的に識別する別の新機能が導入されています。コンパイラは、間接分岐命令の予想される各着地点に、特別な命令 (オペコード「BTI」) を挿入します。これらの識別された分岐先には、通常、関数のエントリポイントとスイッチ/ケースコードブロックが含まれます。

BTI 命令は、コンパイラとリンカーによって「保護」とマークされたコードメモリページで使用されます。保護されたページで、BTI 以外の命令に間接分岐命令が到達すると、エラーが発生します。

BTI命令が挿入される特定された宛先は、平均的なアプリケーションコード内のすべての命令の約1％を占めています。したがって、BTIを使用すると、コードサイズが同じ量だけ増加します。^[29]

ROP 攻撃で使用されるガジェットは、アプリケーションコードの任意の場所にあります。したがって、平均して、ガジェットの 99% は BTI ではない命令で始まります。これらのガジェットに分岐すると、結果的に障害が発生します。ROP 攻撃は複数のガジェットのチェーンで構成されていると考えると、チェーン内のすべてのガジェットが BTI で始まる 1% の一部である可能性は非常に低くなります。

PACとBTIは、リターン指向およびジャンプ指向プログラミング攻撃による不正なコードインジェクションを防ぐための補完的なメカニズムです。PACは分岐操作のソース（符号付きポインタ）に焦点を当てていますが、BTIは分岐の宛先に焦点を当てています。^[30]

参照

注記

^ ab一部の著者は ガジェットという用語を多少異なる意味で使用しており、ガジェットを単なるプログラムロジックの塊、または何らかの望ましいアクションを実行するために作成された短いオペコードのシーケンスと呼んでいます。^[31]

参考文献

^ Vázquez, Hugo (2007-10-01). 「Check Point Secure Platform Hack」(PDF) . Pentest . バルセロナ、スペイン: Pentest Consultores. p. 219.
^ 「スレッド: CheckPoint Secure Platform の複数のバッファオーバーフロー」。Check Point ユーザーグループ。
^ Shacham, Hovav; Buchanan, Erik; Roemer, Ryan; Savage, Stefan. 「Return-Oriented Programming: Exploits Without Code Injection」。2009-08-12に取得。
^ Buchanan, E.; Roemer, R.; Shacham, H.; Savage, S. (2008 年 10 月)。「正しい命令が悪くなるとき: リターン指向プログラミングの RISC への一般化」( PDF)。第 15 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '08 の議事録。pp. 27–38。doi : 10.1145 /1455770.1455776。ISBN 978-1-59593-810-7. S2CID 11176570。
^ Microsoft Windows XP SP2 データ実行防止
^ Solar Designer、Return-into-lib(c) エクスプロイト、Bugtraq
^ Nergal, Phrack 58 第4条、return-into-lib(c) エクスプロイト
^ Sebastian Krahmer、x86-64 バッファオーバーフローエクスプロイトと借用コードチャンクエクスプロイト手法、2005 年 9 月 28 日
^ Abadi, MN; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (2005 年 11 月)。「制御フローの整合性: 原理、実装、およびアプリケーション」。第 12 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '05 の議事録。pp. 340–353。doi : 10.1145 / 1102120.1102165。ISBN 1-59593-226-7. S2CID 3339874。
^ Abadi, MN; Budiu, M.; Erlingsson, Ú .; Ligatti, J. (2009 年 10 月)。「制御フローの整合性の原則、実装、およびアプリケーション」。ACM Transactions on Information and System Security。13 : 1–40。doi : 10.1145 /1609956.1609960。S2CID 207175177。
^ abc Shacham, H. (2007 年 10 月)。「骨の上の無垢な肉の幾何学: 関数呼び出しなしの return-into-libc (x86 上)」。第 14 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '07 の議事録。pp. 552–561。doi :10.1145 / 1315245.1315313。ISBN 978-1-59593-703-2. S2CID 11639591。
^ Jonathan Salwan と Allan Wirth、ROPgadget - ガジェット検索と自動ローパー
^ [Shacham 他、2004] Hovav Shacham、Matthew Page、Ben Pfaff、Eu-Jin Goh、Nagendra Modadugu、および Dan Boneh。アドレス空間のランダム化の有効性について。2004 年、第 11 回 ACM コンピューターおよび通信セキュリティ会議 (CCS) の議事録。
^ [Bennett 他、2013] James Bennett、Yichong Lin、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., Winandy, M. 2010. リターンのないリターン指向プログラミング。CCS 2010 の議事録、A. Keromytis および V. Shmatikov 編。ACM Press、559–572
^ Onarlioglu, K., Bilge, L., Lanzi, A., Balzarotti, D., Kirda, E. 2010.「G-Free: ガジェットのないバイナリによるリターン指向プログラミングの無効化」ACSAC 2010 の Proceedings、M. Franz および J. McDermott 編。ACM Press、49–58 ページ。
^ Skowyra, R.; Casteel, K.; Okhravi, H.; Zeldovich, N.; Streilein, W. (2013 年 10 月)。「Return-Oriented Programming に対する防御の体系的分析」(PDF)。攻撃、侵入、防御の研究。コンピュータサイエンスの講義ノート。第 8145 巻。pp. 82–102。doi : 10.1007/978-3-642-41284-4_5。ISBN 978-3-642-41283-72014年2月22日時点のオリジナル（PDF）よりアーカイブ。
^ Venkat, Ashish; Shamasunder, Sriskanda; Shacham, Hovav; Tullsen, Dean M. (2016-01-01). 「HIPStR」。プログラミング言語とオペレーティングシステムのアーキテクチャサポートに関する第21回国際会議の議事録。ASPLOS '16。ニューヨーク、ニューヨーク、米国：ACM。pp. 727–741。doi : 10.1145 /2872362.2872408。ISBN 9781450340915. S2CID 7853786。
^ Hiser, J.; Nguyen-Tuong, A.; Co, M.; Hall, M.; Davidson, JW (2012 年 5 月)。「ILR: 私のガジェットはどこに行ったのか?」2012 IEEE セキュリティとプライバシーに関するシンポジウム。pp. 571–585。doi : 10.1109 / SP.2012.39。ISBN 978-1-4673-1244-8. S2CID 15696223。
^ US 9135435、Venkat, Ashish、Krishnaswamy, Arvind、Yamada, Koichi 他、「Binary translatordriven program state relocation」、2015-09-15 発行、Intel Corp.に譲渡。
^ Vasilis Pappas. kBouncer: 効率的で透過的な ROP 軽減策。2012 年 4 月。
^ 米国出願 2019347385、Shelly、Asaf、「コード変異によるセキュリティ方法およびシステム」、2019 年 11 月 14 日公開、その後放棄。
^ Francillon, A., Perito, D., Castelluccia, C. 2009. 制御フロー攻撃に対する組み込みシステムの防御。SecuCode 2009 の Proceedings、S. Lachmund および C. Schaefer 編。ACM Press、19–26 ページ。
^ abcd Li, Jinku; Wang, Zhi; Jiang, Xuxian; Grace, Mike; Bahram, Sina. 「return-less」カーネルによる return-ordinated rootkits の無効化。G . Muller 編、EuroSys 2010 論文集。ACM Press、195–208 ページ。
^ Avanzi, Roberto (2016). The QARMA Block Cipher Family (PDF) . IACR Transactions on Symmetric Cryptology (ToSC). Vol. 17 (published 2017-03-08). pp. 4–44. doi :10.13154/tosc.v2017.i1.4-44. 2020-05-13にオリジナル(PDF)からアーカイブ。
^ Qualcomm 製品セキュリティ。「ARMv8.3 でのポインタ認証」(PDF)。Qualcomm Technologies Inc. 2020 年 6 月 6 日にオリジナルからアーカイブ(PDF) 。2020年 6 月 16 日に取得。そこで、軽量で調整可能なブロック暗号の新しいファミリーである QARMA を設計しました。
^ 「Linux 5.7 For 64-bit ARM Brings In-Kernel Pointer Authentication, Activity Monitors - Phoronix」www.phoronix.com . 2020年3月31日閲覧。
^ Ravichandran, Joseph; Na, Weon Taek; Lang, Jay; Yan, Mengjia (2022 年 6 月). 「PACMAN: 投機的実行による ARM ポインター認証への攻撃」. Proceedings of the 49th Annual International Symposium on Computer Architecture . Association for Computing Machinery. doi : 10.1145/3470496.3527429 . hdl : 1721.1/146470 .
^ 「PAC と BTI のテクニックを実際のコードに適用する」。developer.arm.com。2024年2 月 4 日閲覧。
^ 「制御フロー整合性、Arm64 システムでのマルウェア対策アクティブ保護」(PDF) . sipearl.com . 2024 年 2 月 4 日閲覧。
^ Cha, Sang Kil; Pak, Brian; Brumley, David ; Lipton, Richard Jay (2010-10-08) [2010-10-04]. プラットフォームに依存しないプログラム(PDF) . Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University , Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology , Atlanta, Georgia, USA. pp. 547–558. doi :10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. 2022年5月26日時点のオリジナルよりアーカイブ（PDF） . 2022年5月26日閲覧。[1] (12ページ) ([2]も参照) (注: プログラムロジックのチャンクをガジェットという用語で表します。この場合はガジェットヘッダーとガジェット本体に分かれています。)

外部リンク

「コンピュータ科学者が新しいプログラミング技術で電子投票機を制圧」。サイエンスデイリー。2009 年 8 月 11 日。
「リターン指向プログラミング攻撃デモビデオ」。YouTube。^{[ YouTube リンク切れ]}
AntiJOP: アセンブリ言語コードから JOP/ROP の脆弱性を除去するプログラム

[NB_Gadget-5] 一部の著者は ガジェットという用語を多少異なる意味で使用しており、ガジェットを単なるプログラムロジックの塊、または何らかの望ましいアクションを実行するために作成された短いオペコードのシーケンスと呼んでいます。^[31]

[1] Vázquez, Hugo (2007-10-01). 「Check Point Secure Platform Hack」(PDF) . Pentest . バルセロナ、スペイン: Pentest Consultores. p. 219.

[2] 「スレッド: CheckPoint Secure Platform の複数のバッファオーバーフロー」。Check Point ユーザーグループ。

[3] Shacham, Hovav; Buchanan, Erik; Roemer, Ryan; Savage, Stefan. 「Return-Oriented Programming: Exploits Without Code Injection」。2009-08-12に取得。

[4] Buchanan, E.; Roemer, R.; Shacham, H.; Savage, S. (2008 年 10 月)。「正しい命令が悪くなるとき: リターン指向プログラミングの RISC への一般化」( PDF)。第 15 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '08 の議事録。pp. 27–38。doi : 10.1145 /1455770.1455776。ISBN 978-1-59593-810-7. S2CID 11176570。

[6] Microsoft Windows XP SP2 データ実行防止

[7] Solar Designer、Return-into-lib(c) エクスプロイト、Bugtraq

[8] Nergal, Phrack 58 第4条、return-into-lib(c) エクスプロイト

[9] Sebastian Krahmer、x86-64 バッファオーバーフローエクスプロイトと借用コードチャンクエクスプロイト手法、2005 年 9 月 28 日

[10] Abadi, MN; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (2005 年 11 月)。「制御フローの整合性: 原理、実装、およびアプリケーション」。第 12 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '05 の議事録。pp. 340–353。doi : 10.1145 / 1102120.1102165。ISBN 1-59593-226-7. S2CID 3339874。

[11] ^ Abadi, MN; Budiu, M.; Erlingsson, Ú .; Ligatti, J. (2009 年 10 月)。「制御フローの整合性の原則、実装、およびアプリケーション」。ACM Transactions on Information and System Security。13 : 1–40。doi : 10.1145 /1609956.1609960。S2CID 207175177。

[fleshonbone-12] Shacham, H. (2007 年 10 月)。「骨の上の無垢な肉の幾何学: 関数呼び出しなしの return-into-libc (x86 上)」。第 14 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '07 の議事録。pp. 552–561。doi :10.1145 / 1315245.1315313。ISBN 978-1-59593-703-2. S2CID 11639591。

[13] Jonathan Salwan と Allan Wirth、ROPgadget - ガジェット検索と自動ローパー

[14] [Shacham 他、2004] Hovav Shacham、Matthew Page、Ben Pfaff、Eu-Jin Goh、Nagendra Modadugu、および Dan Boneh。アドレス空間のランダム化の有効性について。2004 年、第 11 回 ACM コンピューターおよび通信セキュリティ会議 (CCS) の議事録。

[15] [Bennett 他、2013] James Bennett、Yichong Lin、Thoufique Haq。The Number of the Beast、2013 年。https://www.fireeye.com/blog/threat-research/2013/02/the-number-of-the-beast.html

[16] Checkoway, S., Davi, L., Dmitrienko, A., Sadeghi, A.-R., Shacham, H., Winandy, M. 2010. リターンのないリターン指向プログラミング。CCS 2010 の議事録、A. Keromytis および V. Shmatikov 編。ACM Press、559–572

[17] Onarlioglu, K., Bilge, L., Lanzi, A., Balzarotti, D., Kirda, E. 2010.「G-Free: ガジェットのないバイナリによるリターン指向プログラミングの無効化」ACSAC 2010 の Proceedings、M. Franz および J. McDermott 編。ACM Press、49–58 ページ。

[18] Skowyra, R.; Casteel, K.; Okhravi, H.; Zeldovich, N.; Streilein, W. (2013 年 10 月)。「Return-Oriented Programming に対する防御の体系的分析」(PDF)。攻撃、侵入、防御の研究。コンピュータサイエンスの講義ノート。第 8145 巻。pp. 82–102。doi : 10.1007/978-3-642-41284-4_5。ISBN 978-3-642-41283-72014年2月22日時点のオリジナル（PDF）よりアーカイブ。

[19] Venkat, Ashish; Shamasunder, Sriskanda; Shacham, Hovav; Tullsen, Dean M. (2016-01-01). 「HIPStR」。プログラミング言語とオペレーティングシステムのアーキテクチャサポートに関する第21回国際会議の議事録。ASPLOS '16。ニューヨーク、ニューヨーク、米国：ACM。pp. 727–741。doi : 10.1145 /2872362.2872408。ISBN 9781450340915. S2CID 7853786。

[20] Hiser, J.; Nguyen-Tuong, A.; Co, M.; Hall, M.; Davidson, JW (2012 年 5 月)。「ILR: 私のガジェットはどこに行ったのか?」2012 IEEE セキュリティとプライバシーに関するシンポジウム。pp. 571–585。doi : 10.1109 / SP.2012.39。ISBN 978-1-4673-1244-8. S2CID 15696223。

[21] US 9135435、Venkat, Ashish、Krishnaswamy, Arvind、Yamada, Koichi 他、「Binary translatordriven program state relocation」、2015-09-15 発行、Intel Corp.に譲渡。

[22] Vasilis Pappas. kBouncer: 効率的で透過的な ROP 軽減策。2012 年 4 月。

[23] 米国出願 2019347385、Shelly、Asaf、「コード変異によるセキュリティ方法およびシステム」、2019 年 11 月 14 日公開、その後放棄。

[24] Francillon, A., Perito, D., Castelluccia, C. 2009. 制御フロー攻撃に対する組み込みシステムの防御。SecuCode 2009 の Proceedings、S. Lachmund および C. Schaefer 編。ACM Press、19–26 ページ。

[Li2010-25] Li, Jinku; Wang, Zhi; Jiang, Xuxian; Grace, Mike; Bahram, Sina. 「return-less」カーネルによる return-ordinated rootkits の無効化。G . Muller 編、EuroSys 2010 論文集。ACM Press、195–208 ページ。

[26] Avanzi, Roberto (2016). The QARMA Block Cipher Family (PDF) . IACR Transactions on Symmetric Cryptology (ToSC). Vol. 17 (published 2017-03-08). pp. 4–44. doi :10.13154/tosc.v2017.i1.4-44. 2020-05-13にオリジナル(PDF)からアーカイブ。

[27] Qualcomm 製品セキュリティ。「ARMv8.3 でのポインタ認証」(PDF)。Qualcomm Technologies Inc. 2020 年 6 月 6 日にオリジナルからアーカイブ(PDF) 。2020年 6 月 16 日に取得。そこで、軽量で調整可能なブロック暗号の新しいファミリーである QARMA を設計しました。

[28] 「Linux 5.7 For 64-bit ARM Brings In-Kernel Pointer Authentication, Activity Monitors - Phoronix」www.phoronix.com . 2020年3月31日閲覧。

[29] Ravichandran, Joseph; Na, Weon Taek; Lang, Jay; Yan, Mengjia (2022 年 6 月). 「PACMAN: 投機的実行による ARM ポインター認証への攻撃」. Proceedings of the 49th Annual International Symposium on Computer Architecture . Association for Computing Machinery. doi : 10.1145/3470496.3527429 . hdl : 1721.1/146470 .

[30] 「PAC と BTI のテクニックを実際のコードに適用する」。developer.arm.com。2024年2 月 4 日閲覧。

[31] 「制御フロー整合性、Arm64 システムでのマルウェア対策アクティブ保護」(PDF) . sipearl.com . 2024 年 2 月 4 日閲覧。

[Cha-Pak-Brumley-Lipton_2010-32] Cha, Sang Kil; Pak, Brian; Brumley, David ; Lipton, Richard Jay (2010-10-08) [2010-10-04]. プラットフォームに依存しないプログラム(PDF) . Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University , Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology , Atlanta, Georgia, USA. pp. 547–558. doi :10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. 2022年5月26日時点のオリジナルよりアーカイブ（PDF） . 2022年5月26日閲覧。[1] (12ページ) ([2]も参照) (注: プログラムロジックのチャンクをガジェットという用語で表します。この場合はガジェットヘッダーとガジェット本体に分かれています。)

背景