SFOP：研究人員展示如何用 Segmentation Fault 繞過 Intel CET

現代 CPU 已經加入愈來愈多硬體安全防護，希望阻止記憶體破壞（memory corruption）導致的攻擊。Intel 的 Control‑Flow Enforcement Technology（CET） 就是其中一個重要機制，目的係令常見的 code‑reuse 攻擊（例如 ROP）變得更難成功。

不過最新研究指出，就算有硬體保護，如果作業系統的行為可以被濫用，仍然可能出現繞過方法。

由 CISPA Helmholtz Center for Information Security 研究人員提出的一種新技術——Segmentation Fault Oriented Programming（SFOP）——展示咗如何利用 Linux 的訊號處理機制，在 CET 啟用的情況下仍然控制程式流程。相關研究亦在 2026 年 IEEE Symposium on Security and Privacy 的討論中出現。

什麼是 SFOP（Segmentation Fault Oriented Programming）

SFOP 屬於一種 serial code‑reuse attack（序列式程式碼重用攻擊）。核心概念係：故意令程式反覆產生 segmentation fault，再利用 signal handler 作為新的控制流程入口。

典型攻擊流程大致如下：

• 攻擊者誘導程式存取非法記憶體地址
• 系統觸發 segmentation fault（SIGSEGV）
• Linux 將控制權交畀該程式註冊的 signal handler
• signal handler 進一步準備下一次 crash 或下一步執行

透過不斷重複這個循環，攻擊者可以逐步串接一連串操作。每一次 crash 都成為攻擊鏈的一部分，最終利用程式或共享函式庫中的現有程式碼完成惡意行為。

與傳統 Return‑Oriented Programming（ROP） 不同，SFOP 並不是依靠操控 return address，而是利用 連續 fault 事件與 signal handler 來推進控制流程。

Intel CET 原本想解決什麼問題

Intel 推出的 Control‑Flow Enforcement Technology（CET） 是一種硬體層安全機制，目標係阻止 code‑reuse 攻擊。

CET 主要包含兩類保護：

• 驗證函式返回地址（shadow stack）
• 限制間接跳轉的合法目標

理論上，這些機制可以阻止攻擊者將程式跳轉到不應該執行的位置。

但 CET 的設計主要針對 程式內部的不合法控制流程。

SFOP 則完全繞開這個假設。

SFOP 如何在 Linux 上繞過 CET

SFOP 的關鍵洞察是：

訊號傳遞本身就是作業系統合法的控制流程轉移。

大致攻擊步驟如下：

1. 攻擊者令程式存取受限制記憶體，觸發 segmentation fault
2. Linux 產生 SIGSEGV 訊號
3. 系統將執行流程轉移到註冊好的 signal handler
4. handler 設置下一個 fault 條件
5. 程式再次崩潰並觸發下一次 signal

在這個模型下，每一個 signal handler 都變成攻擊鏈的一個節點。

由於這些轉移是 OS 合法觸發的控制流程，因此可以避開 CET 對一般 indirect branch 或 return 的檢查。

結果就是：攻擊者可以逐步拼湊程式既有代碼，最終達到 arbitrary code execution（任意程式碼執行）。

Linux SIGSEGV 機制為何會成為攻擊工具

在 Linux 中，程式可以為多種訊號註冊 handler，包括 SIGSEGV。這些 handler 原本用途是：

• 記錄錯誤
• 嘗試復原
• 做診斷或除錯

SFOP 將這個設計反過來利用：

• 重複觸發 segmentation fault
• 每次都進入 signal handler
• 在 handler 中改變下一步行為

於是，signal handler 本身就變成一個 可重用的控制流程 building block。

可能的防禦與緩解措施

研究人員提出了幾種可能減低 SFOP 風險的方向。

Linux Kernel 強化

其中一個方向是 修改 Linux kernel 的 signal handling 行為，限制攻擊者反覆利用 segmentation fault 和 signal handler 來建立攻擊鏈。

目前公開資料提到已有 kernel 層面的修補構想，但詳細實作仍未在公開報告中完整披露。

PLaTypus Hardening Layer

另一個研究提出的防護機制叫 PLaTypus。

研究人員發現，即使 CET 已啟用，攻擊者仍然可以透過 跨共享函式庫（shared library）跳轉 來拼湊攻擊鏈。

PLaTypus 的做法是：

• 大幅限制 跨 library 的間接跳轉
• 盡量只允許在同一個 library 內部轉移

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

為什麼 SFOP 研究值得關注

SFOP 再次提醒安全研究界一件事：

單靠硬體安全機制並不足夠。

即使 CPU 已經加入像 CET 這樣的保護，只要作業系統層仍然提供可被濫用的合法控制流程，攻擊者仍然可能找到繞過方法。

對系統安全工程師來說，真正有效的防護需要同時考慮整個技術棧：

• CPU 硬體機制
• 作業系統設計
• 程式庫與應用程式結構

因為攻擊者往往只需要找到 其中一層的可利用入口。