SFOP：研究人員發現可利用 Segmentation Fault 繞過 Intel CET 的新型 Linux 攻擊

典型攻擊流程如下：

• 攻擊者讓程式存取非法記憶體位置
• 系統觸發 SIGSEGV（segmentation fault signal）
• Linux 將控制權轉移到程式註冊的 signal handler
• handler 設定下一個故意造成崩潰的步驟

當這個流程不斷重複時，每一次崩潰都成為攻擊鏈的一個節點。攻擊者可以利用程式本身或其函式庫中的既有程式碼，逐步組合出想要的行為。

這與傳統的 Return‑Oriented Programming（ROP） 有明顯差異：

• ROP：操控返回地址
• SFOP：操控「錯誤與訊號處理流程」

換句話說，SFOP 把 程式崩潰本身變成一種可重用的控制流程工具。

Intel CET 原本的設計目標

Intel 的 Control‑Flow Enforcement Technology（CET） 是為了防止程式碼重用攻擊而設計的硬體防護機制。

這項技術自 Intel 第 10、11 代 Core 處理器開始逐步導入，並已整合到較新的 Windows 與 Linux 系統中。

CET 主要包含兩類保護：

• 驗證函式返回位址（例如 shadow stack）
• 限制間接跳轉（indirect branch targets）

其目標是阻止攻擊者把程式執行流程跳轉到不預期的指令位置。

但 CET 的保護範圍主要集中在 程式正常執行路徑中的控制流程轉移。

而 SFOP 則繞過這個假設。

SFOP 如何在 Linux 上繞過 CET

SFOP 的關鍵洞察是：

訊號傳遞（signal delivery）本身就是作業系統允許的合法控制流程轉移。

攻擊流程大致如下：

1. 攻擊者讓程式存取受限制的記憶體
2. Linux 觸發 SIGSEGV
3. 核心將控制權交給程式的 signal handler
4. handler 設計下一次崩潰或下一個執行步驟

接著同樣流程再次發生。

每一次 signal handler 的執行，都成為攻擊鏈的一個「節點」。由於這種轉移是由作業系統合法觸發，而不是非法的 indirect jump 或 return，因此可以避開 CET 對控制流程的檢查。

透過多次錯誤與 handler 的連續觸發，攻擊者就能逐步組裝出複雜的行為，最終達到 任意程式碼執行（arbitrary code execution）。

Linux SIGSEGV 訊號處理為何成為攻擊基礎

在 Linux 中，程式可以註冊 SIGSEGV handler 來處理 segmentation fault。

這通常用於：

• 記錄錯誤
• 嘗試恢復程式
• 提供診斷資訊

SFOP 正是利用了這個設計：

• 每次故意觸發 segmentation fault
• Linux 呼叫 handler
• handler 改變下一步執行環境

因此，signal handling 本身就被轉化為一種可重用的控制流程原語（control‑flow primitive）。

可能的防禦措施

Linux 核心強化

研究摘要指出，一種防禦方向是修改 Linux 的訊號處理行為，以限制攻擊者利用重複 segmentation fault 作為控制流程機制的能力。

公開報告提到存在核心層級的修補方向，但目前公開資訊仍未完整揭露所有實作細節。

PLaTypus 強化層

另一個研究方向是 PLaTypus 安全強化機制。

研究人員發現，即使 CET 啟用，攻擊者仍可能透過不同共享函式庫之間的跳轉來建立攻擊鏈。

PLaTypus 的做法是：

• 限制間接控制流程跳轉
• 儘量保持跳轉在同一個函式庫內
• 僅在明確允許時才跨函式庫

這樣可以大幅減少攻擊者可利用的 code‑reuse 目標。

為什麼這項研究重要

SFOP 的出現揭示了一個重要現實：

單靠 CPU 硬體防護並不足以完全阻止控制流程攻擊。

如果作業系統的合法機制（例如訊號處理）仍然能被濫用，攻擊者就可能在防護之間找到縫隙。

對資安工程師而言，這意味著防禦策略必須跨越整個技術堆疊，包括：

• CPU 硬體防護
• 作業系統核心設計
• 程式與函式庫的安全策略

隨著 CET 與類似技術逐漸成為標準，像 SFOP 這類研究也為下一代防護機制提供了重要線索。