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

與傳統 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 硬體機制
• 作業系統設計
• 程式庫與應用程式結構

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