SFOP：通过“分段错误编程”绕过Intel CET的Linux新型攻击技术

攻击流程通常如下：

• 攻击者让程序访问非法内存地址，触发 segmentation fault（SIGSEGV）。
• Linux操作系统捕获该异常，并调用程序注册的信号处理函数。
• 攻击者控制该处理函数，使其为下一次崩溃或执行步骤做准备。
• 程序再次触发错误并重复上述流程。

通过不断重复这一过程，攻击者能够构建一条执行链。每一次崩溃和信号处理都会推进攻击步骤，从而逐步实现攻击者期望的行为。

与传统的 Return‑Oriented Programming（ROP） 不同，SFOP不是依赖操纵返回地址，而是利用 连续的异常与信号处理事件 来驱动控制流。

Intel CET原本如何防御攻击

Control‑Flow Enforcement Technology（CET） 是Intel推出的硬件级安全机制，用于阻止代码复用攻击。该技术自Intel第10和第11代Core处理器起逐步部署，并集成到较新的Windows和Linux系统中。

CET的核心目标是确保程序控制流不会被非法重定向，例如：

• 验证函数返回地址是否被篡改
• 限制间接跳转目标

通过这些机制，攻击者很难跳转到程序中任意指令位置来拼接恶意执行路径。

SFOP如何绕过CET

SFOP利用的关键点是：信号处理本身是操作系统允许的合法控制流转移。

简化后的攻击步骤如下：

1. 攻击代码让程序访问受限内存，引发分段错误。
2. Linux生成 SIGSEGV 信号并转入信号处理程序。
3. 信号处理程序执行攻击者控制的逻辑，例如设置新的错误触发条件。
4. 程序再次崩溃并触发下一次信号处理。

每一次信号处理函数的执行都成为攻击链中的一个节点。由于这是 操作系统合法触发的执行路径，因此不会被CET的控制流检查机制直接阻止。

通过这种方式，攻击者可以利用程序和共享库中现有的代码逐步拼接行为，最终实现 任意代码执行（arbitrary code execution）。

Linux信号机制为何成为攻击入口

在Linux中，程序可以为不同信号注册处理函数。例如：

• SIGSEGV（分段错误）
• SIGILL（非法指令）
• SIGBUS（总线错误）

这些处理函数通常用于记录日志或尝试恢复程序运行。但SFOP将这种错误恢复机制变成了一种 可重复使用的控制流原语：

• 每一次崩溃都会触发处理函数
• 处理函数可以改变程序状态
• 下一次崩溃继续推进攻击流程

因此，程序崩溃不再只是异常事件，而成为攻击逻辑的一部分。

研究人员提出的缓解措施

Linux内核层面的加固

一种思路是修改Linux内核对信号处理的机制，使攻击者难以通过连续的SIGSEGV触发来构造控制流链。已有研究提到相关补丁思路，但公开资料中尚未披露完整实现细节。

PLaTypus安全加固层

研究人员还提出一种名为 PLaTypus 的加固机制，用于强化CET在真实系统中的防护能力。

研究发现，即使启用了CET，攻击者仍然可能在 不同共享库之间进行控制流跳转，从而继续拼接可利用的代码路径。

PLaTypus的核心策略包括：

• 限制间接跳转跨越不同程序库
• 尽量保持控制流在同一库内部
• 只允许明确授权的跨库跳转

这样可以大幅减少攻击者可利用的代码复用目标，从而降低类似SFOP攻击成功的概率。

为什么这项研究重要

SFOP揭示了一个关键事实：硬件安全机制并不是孤立存在的。

即使像Intel CET这样先进的CPU级防护，如果操作系统层面的行为仍然可以提供可利用的控制流路径，攻击者仍然可能找到绕过方式。

对系统安全工程师而言，这项研究的意义在于：

• 安全设计必须覆盖 CPU、操作系统和软件栈的整体
• 合法系统机制（例如信号处理）也可能成为攻击工具
• 硬件防护需要与操作系统策略协同强化

随着CET等硬件安全特性在现代操作系统中逐渐普及，这类研究将帮助发现隐藏的设计缺口，并推动下一代系统安全机制的改进。