SFOP：セグメンテーションフォルトを利用してIntel CETを回避する新しい攻撃

このサイクルを何度も繰り返すことで、クラッシュそのものを“制御フローのステップ”として利用できるようになります。

従来の攻撃（Return‑Oriented Programmingなど）は、関数のリターンアドレスを書き換えて既存コードをつなぎ合わせます。

一方SFOPでは、連続するフォルト処理を利用して実行の流れを段階的に進めるという点が大きく異なります。

Intel CETは本来どんな防御なのか

Intel CETは、CPUレベルで制御フローの整合性を守るための仕組みです。

主に以下のような攻撃を防ぐ目的があります。

• Return‑Oriented Programming（ROP）
• Jump‑Oriented Programming（JOP）
• 既存コードを組み合わせるコード再利用攻撃

CETは次のような仕組みで保護を行います。

• シャドウスタックによるリターンアドレス検証
• 間接分岐ターゲット制御によるジャンプ制限

これにより、プログラムの想定外の命令へ飛ぶことを防ぐ設計になっています。

しかしCETが想定しているのは、プログラム内部の不正な制御フロー遷移です。

SFOPはそこを回避し、OSが正当に行うシグナル処理を利用するという別ルートを使います。

SFOPがCETを回避する仕組み

SFOPの核心は、シグナル配送そのものが合法的な制御フロー遷移であるという点です。

攻撃の大まかな流れは以下の通りです。

1. 攻撃者が不正メモリアクセスを起こし、セグメンテーションフォルトを発生させる
2. LinuxがSIGSEGVシグナルを送信
3. プログラムのシグナルハンドラへ実行が移る
4. ハンドラが次のクラッシュを引き起こす処理を仕込む

これにより

• フォルト
• シグナルハンドラ
• 次のフォルト

という連鎖が作られます。

つまり各シグナルハンドラが攻撃チェーンの1ステップになるわけです。

この遷移はOSが正当に行う処理のため、CETが検査する「不正な分岐」には該当しない可能性があると研究者は指摘しています。

その結果、攻撃者は既存コードを組み合わせて最終的に任意コード実行に至る可能性があります。

LinuxのSIGSEGVシグナル処理が攻撃に利用される理由

Linuxでは、プログラムがクラッシュした際にSIGSEGVハンドラを登録しておくことで、次のような処理を行えます。

• エラーログの記録
• メモリ状態の調査
• プログラムの復旧処理

SFOPはこの仕組みを逆手に取り、

• 意図的にクラッシュを発生
• ハンドラを呼び出させる
• 次のクラッシュ条件を作る

というループを作ります。

その結果、クラッシュ処理自体が攻撃の制御フロープリミティブ（再利用可能な動作単位）として機能するようになります。

提案されている対策

研究では、この攻撃に対抗するためにいくつかの対策が議論されています。

Linuxカーネルのハードニング

一つの方向性は、Linuxカーネル側でシグナル処理の挙動を強化することです。

公開されている概要では、セグメンテーションフォルトの連続利用やシグナルハンドラの悪用を難しくするカーネルレベルの修正が提案されています。ただし現時点の公開情報では、具体的なパッチ詳細は限定的です。

PLaTypusハードニングレイヤー

もう一つの提案が、PLaTypusという研究段階の防御レイヤーです。

研究者は、CETが有効でも攻撃者が異なる共有ライブラリ間を自由にジャンプできることを問題として指摘しました。

PLaTypusは次のような対策を行います。

• 間接ジャンプの範囲を制限
• 原則として同一ライブラリ内に遷移を限定
• 必要な場合のみライブラリ間遷移を許可

これにより、攻撃で利用できるコード断片（ガジェット）の数を大幅に減らすことができます。

なぜSFOP研究が重要なのか

SFOPは、現代のセキュリティ設計に重要な教訓を示しています。

それは、

**「ハードウェア防御だけでは不十分で、OSの挙動も含めたシステム全体を守る必要がある」**という点です。

CETのような高度な防御があっても、攻撃者は

• OSのシグナル処理
• ライブラリ間遷移
• 例外処理

といった別のレイヤーを足がかりにします。

こうした研究は、CPU・OS・アプリケーションを含むスタック全体の防御設計を見直すきっかけになると考えられています。