发布于 由admin

什么是 ‘Control Flow Guard’ (CFG)？解析编译器如何拦截针对虚函数表的非法跳转攻击？

各位同仁、各位专家，

欢迎来到今天的讲座。我们今天将深入探讨一个在现代软件安全领域至关重要的主题：Control Flow Guard (CFG)。我们将不仅仅停留于概念层面，更会剖析其底层的实现机制，特别是编译器与操作系统如何协同工作，以及CFG如何有效地拦截那些试图通过篡改虚函数表来劫持程序控制流的非法攻击。

在当今复杂的软件环境中，程序漏洞层出不穷。攻击者利用这些漏洞，其终极目标往往是劫持程序的控制流，使其执行恶意代码。为了对抗这种威胁，我们引入了一系列防御机制，而CFG正是其中一道关键的防线。

I. 引言：控制流劫持的威胁与防御的必要性

程序执行的本质，可以被抽象为一系列指令的有序执行，这个执行序列就是我们所说的“控制流”。一个程序从启动到终止，其控制流遵循着预设的逻辑路径：函数调用、函数返回、条件分支、循环等。这些路径在程序编译时就已经确定，并在运行时通过特定的指令（如 CALL、JMP、`RET 等）来实现。

然而，攻击者正是利用软件中的各种缺陷（例如缓冲区溢出、格式化字符串漏洞、Use-After-Free 等），试图篡改程序的内存状态，进而改变程序的控制流。一旦控制流被劫持，攻击者就可以强行让程序跳转到任意指定的内存地址，执行他们精心构造的恶意代码，从而完全控制受感染的进程。

传统的防御机制，如数据执行保护（Data Execution Prevention, DEP）和地址空间布局随机化（Address Space Layout Randomization, ASLR），在一定程度上提高了攻击的难度。DEP通过将数据页标记为不可执行，阻止攻击者直接在栈或堆上执行shellcode。ASLR则通过随机化程序模块、栈、堆等关键内存区域的基地址，使得攻击者难以预测其目标地址。

然而，随着攻击技术的发展，这些防御措施逐渐暴露出局限性。攻击者不再需要将自己的恶意代码直接注入到可执行内存中。他们发展出了“返回导向编程”（Return-Oriented Programming, ROP）和“跳转导向编程”（Jump-Oriented Programming, JOP）等技术。这些技术的核心思想是利用程序自身代码段中已经存在的、合法的指令片段（称为“gadgets”），将它们串联起来，从而绕过DEP并构建任意复杂的恶意逻辑。由于这些gadgets本身是程序合法的可执行代码，DEP无法阻止它们的执行。ASLR虽然增加了寻找这些gadgets的难度，但一旦地址被泄露，攻击者依然可以构建有效的ROP链。

面对ROP/JOP这类高级攻击，我们需要更强大的防御机制，能够确保程序在任何时刻都只跳转到合法的、预期的执行路径上。这就是“控制流完整性”（Control Flow Integrity, CFI）概念诞生的背景。CFI旨在阻止程序执行任何非预期的控制流转移，从而根本上遏制控制流劫持攻击。Control Flow Guard (CFG)正是微软在Windows平台上实现的一种重要的CFI机制。

II. 控制流完整性 (CFI) 的基础理论

控制流完整性（CFI）的核心思想是：程序在运行时所采取的任何控制流转移（无论是跳转、调用还是返回），都必须是预先在编译时或链接时静态分析所确定的合法转移之一。换句话说，CFI 强制程序只沿着“白名单”中的路径前进。

CFI 可以根据其粒度分为细粒度CFI和粗粒度CFI：

  • 细粒度CFI：试图在每个可能的控制流转移点上，精确地验证目标地址的合法性，确保跳转到的是唯一一个或几个允许的目标。实现难度和性能开销通常较大。
  • 粗粒度CFI：在一个更宽泛的范围内进行验证，例如，允许跳转到某个函数的所有入口点，而不是某个特定函数签名的精确匹配。CFG就属于粗粒度CFI。

CFI 也可以根据其保护的控制流转移类型分为前向边CFI和后向边CFI：

  • 后向边CFI：主要关注函数返回指令（RET）。攻击者常常通过栈溢出覆盖函数返回地址来劫持控制流。Stack Canaries（栈金丝雀）和更高级的Shadow Stacks（影子栈）是防御后向边攻击的典型机制。Stack Canaries在函数入口时在返回地址前压入一个随机值，在函数返回前检查此值是否被修改。Shadow Stacks则在另一个独立的、受保护的栈上维护返回地址的副本，并在返回时进行比对。
  • 前向边CFI：主要关注间接调用（CALL [reg/mem]）和间接跳转（JMP [reg/mem]）指令。这些指令的目标地址在编译时通常无法完全确定，它们可能指向多个不同的函数或代码块，例如虚函数调用、函数指针调用、switch-case语句中的跳转表等。CFG正是针对前向边攻击的防御机制。

III. Control Flow Guard (CFG) 的诞生与核心原理

Control Flow Guard (CFG) 是微软在 Windows 8.1 Update 3 和 Windows 10 及更高版本中引入的一项安全功能。它的主要目标是防止程序中的间接调用或跳转指令，将控制权转移到非预期的、非法的目标地址。

CFG 的设计哲学是在提供有效安全防护的同时，尽量减少对程序性能的影响。它通过一种粗粒度的前向边CFI机制来实现这一目标。其核心思想可以概括为以下两点：

  1. 编译时识别与标记： 在程序编译和链接阶段，编译器和链接器会识别出程序中所有可能成为间接调用或间接跳转目标的合法函数入口点。这些合法的目标地址会被特殊标记，例如在可执行文件（PE文件）的某个特定区域中维护一个位图（bitmap）或地址列表。
  2. 运行时验证： 在程序运行时，每当遇到一个间接调用或间接跳转指令时，操作系统或运行时库会介入，检查目标地址是否已被标记为合法的控制流目标。如果目标地址不在预先确定的合法目标列表中，或者不属于一个包含合法目标的内存页，则立即终止程序执行，从而阻止攻击。

CFG 不会尝试验证每一次代码跳转的精确目标，而是通过验证目标地址的“合法性”来阻止大多数恶意跳转。例如，它通常只允许间接调用跳转到函数入口点。如果攻击者试图通过间接调用跳转到函数内部的某个ROP gadget，而这个gadget的地址不是一个函数入口点，CFG就会阻止这次跳转。

这种设计有效地阻止了许多利用内存破坏漏洞（如堆溢出、Use-After-Free）来篡改函数指针或虚函数表，进而劫持控制流的攻击。

IV. CFG 的实现细节：编译器与操作系统的协同

CFG 的实现需要编译器和操作系统的紧密协作。编译器负责在编译时识别和准备必要的信息，并修改代码以进行运行时检查；操作系统则负责在运行时提供验证服务，并强制执行安全策略。

A. 编译器侧的介入 (编译时)

当开发者使用支持CFG的编译器（如MSVC的/guard:cf选项）编译项目时，编译器会执行以下关键步骤：

  1. 识别间接调用/跳转指令： 编译器会扫描所有代码，识别出所有的间接调用指令（如 C/C++ 中的函数指针调用、虚函数调用）和间接跳转指令（如 switch 语句中的跳转表）。在汇编层面，这些通常表现为 CALL [reg/mem] 或 JMP [reg/mem]。

  2. 生成合法目标地址列表：

    • 编译器会遍历所有函数，并将它们的入口点地址标记为合法的间接调用目标。
    • 对于C++虚函数，编译器会将每个虚函数的实际入口点地址加入到这个列表中。
    • 对于 switch 语句中的跳转表，如果跳转目标是代码段中的特定标签，这些标签地址也可能被考虑，但CFG主要关注函数入口。

  3. 标记合法目标信息到 PE 文件：

    • 在链接阶段，链接器会收集所有编译单元生成的合法目标信息。

    • 在最终的可执行文件（PE文件，如.exe或.dll）中，链接器会创建一个特殊的结构来存储这些合法目标的信息。微软的实现通常是在 .rdata 或其他只读数据段中维护一个位图 (bitmap) 或一个地址列表。

      • 位图机制：一种常见且高效的方式是为进程的虚拟地址空间创建一个位图。位图中的每个比特位对应一个内存页（通常是4KB）。如果某个内存页包含至少一个CFG标记的合法函数入口点，则该页对应的比特位会被设置为1。这种方式允许在运行时进行快速的页粒度检查。
      • 地址列表机制：更精确的实现可能会维护一个包含所有合法函数入口地址的列表。这个列表在PE文件中会有一个特定的标记，指示其内容是CFG的目标地址。

    • PE 文件头中的 LOAD_CONFIG_CODE_INTEGRITY_FLAGS 字段会指示该模块是否启用了CFG，以及是否使用了位图或地址列表。

  4. 插入运行时检查代码：

    • 这是最关键的一步。编译器会在每个识别到的间接调用或间接跳转指令之前，插入一段额外的代码。
    • 这段代码会调用一个特殊的运行时检查函数，通常是一个由操作系统或C运行时库提供的桩函数（stub），例如 __guard_check_icall_stub。
    • 这个桩函数负责将要跳转的目标地址传递给操作系统内核，由内核进行实际的验证。

    让我们通过伪代码和汇编示例来理解这个过程：

    原始 C/C++ 代码（函数指针调用为例）：

    // 假设这是一个函数指针
typedef void (*FuncPtr)();

void TargetFunction1() { /* ... */ }
void TargetFunction2() { /* ... */ }

int main() {
    FuncPtr pFunc = TargetFunction1;
    // ...
    // 间接调用
    pFunc();
    // ...
    pFunc = TargetFunction2;
    pFunc();
    return 0;
}

    编译器转换后的伪 C/C++ 代码（概念性）：

    typedef void (*FuncPtr)();

void TargetFunction1() { /* ... */ }
void TargetFunction2() { /* ... */ }

// 运行时由操作系统或运行时库提供的检查函数
// 实际实现会更复杂，可能涉及系统调用
extern "C" bool __guard_validate_target(void* target_address);

int main() {
    FuncPtr pFunc = TargetFunction1;
    // ...
    // 编译器在间接调用前插入 CFG 检查
    if (!__guard_validate_target(pFunc)) {
        // 如果目标地址不合法，则触发快速失败并终止进程
        __fastfail(FAST_FAIL_CFG_ICALL);
    }
    pFunc(); // 原始的间接调用

    // ...
    pFunc = TargetFunction2;
    if (!__guard_validate_target(pFunc)) {
        __fastfail(FAST_FAIL_CFG_ICALL);
    }
    pFunc();
    return 0;
}

    汇编层面示例 (x64 架构，假设 pFunc 的值在 RCX 寄存器中)：

    原始汇编代码片段（间接调用）：

    ; ... 其他指令 ...
mov rcx, [rbp + func_ptr_offset] ; 将函数指针加载到 RCX
call rcx                         ; 间接调用
; ...

    编译器插入 CFG 检查后的汇编代码片段：

    ; ... 其他指令 ...
mov rcx, [rbp + func_ptr_offset] ; 将函数指针加载到 RCX (作为目标地址)

; 编译器插入的 CFG 检查逻辑
push rcx                         ; 将目标地址压栈，或保存到其他寄存器
                                 ; 某些 CFG 桩函数会直接从特定寄存器读取，
                                 ; 例如将目标地址放在 RDX 或 R8
call __guard_check_icall_stub    ; 调用 CFG 检查桩函数
                                 ; 这个桩函数会从栈或特定寄存器获取目标地址，
                                 ; 然后调用操作系统 API 进行验证。
                                 ; 如果验证失败，它将不会返回，而是触发 __fastfail。

pop rcx                          ; 恢复目标地址到 RCX (如果之前压栈了)
                                 ; 或者直接使用之前已保存的寄存器

call rcx                         ; 如果 CFG 检查通过，则执行原始的间接调用
; ...

    __guard_check_icall_stub 是一个由微软运行时库 (vcruntime.dll) 提供的函数，它会进一步调用 Windows 内核 API (ntdll.dll!LdrpValidateUserCallTarget) 来执行实际的验证。

B. 操作系统侧的介入 (运行时)

当程序执行到 __guard_check_icall_stub 并将其控制流转移给操作系统时，操作系统内核或其核心运行时组件（ntdll.dll）会执行以下操作：

  1. 接收验证请求： ntdll.dll 中的 LdrpValidateUserCallTarget 或类似函数会接收到来自用户模式的验证请求，请求验证一个特定的目标地址是否合法。

  2. 查询 CFG 状态： 操作系统会查询该进程的 CFG 状态信息。这些信息是在程序加载时，从 PE 文件中读取并构建的（例如，从 .rdata 段中的位图或地址列表）。

  3. 执行内存页粒度检查：

    • 首先，操作系统会检查目标地址所在的内存页。它会查询一个内部的位图，快速判断该内存页是否被标记为包含CFG合法目标。
    • 如果该页没有被标记，那么目标地址显然是非法的，验证立即失败。
    • 这种页粒度检查非常高效，因为它避免了对每个地址进行精确查找的开销。

  4. 执行精确地址检查（如果需要）：

    • 如果目标地址所在的内存页被标记为包含合法目标，操作系统可能会进行更精确的检查。
    • 它会查找 PE 文件中存储的精确合法地址列表，确认目标地址是否与列表中的某个合法函数入口地址完全匹配。
    • 对于某些优化，如果一个页被标记，且该页内所有可执行代码都被认为是合法目标（例如，某些旧版或配置下的粗粒度CFG），则可能省略精确匹配。但在更严格的CFG实现中，精确匹配是必要的。

  5. 快速失败机制：

    • 如果验证通过，LdrpValidateUserCallTarget 函数会返回，允许 __guard_check_icall_stub 将控制流返回给调用者，然后执行原始的间接调用。
    • 如果验证失败（目标地址不合法），操作系统不会将控制流返回给用户模式代码。相反，它会立即通过 __fastfail 机制终止进程。__fastfail 是一种轻量级的进程终止机制，它会生成一个非法的控制流转移异常（FAST_FAIL_CFG_ICALL），并迅速结束进程。这种快速终止阻止了攻击者进一步利用被劫持的控制流，有效地将潜在的攻击限制在最初的尝试阶段。

通过编译器和操作系统的协同，CFG在不显著增加运行时开销的前提下，建立了一道强大的防线，确保了程序控制流的完整性。

V. CFG 如何拦截针对虚函数表的非法跳转攻击

现在，让我们聚焦于CFG如何特别有效地防御针对虚函数表的非法跳转攻击，也就是我们常说的“虚函数表劫持”（VTable Hijacking）。

A. 虚函数 (Virtual Functions) 与虚函数表 (VTable)

在 C++ 等面向对象语言中，虚函数是实现多态性的核心机制。当通过基类指针或引用调用派生类对象的虚函数时，编译器在编译时无法确定具体调用哪个版本的函数，而是在运行时根据对象的实际类型来决定。

为了实现这种运行时多态，C++ 引入了虚函数表 (Virtual Function Table, VTable) 和虚表指针 (Virtual Table Pointer, vptr)。

  • vptr： 每个含有虚函数的类对象（或其基类含有虚函数），都会在其内存布局的起始位置包含一个隐藏的指针，即 vptr。这个 vptr 指向该对象所属类的 VTable。
  • VTable： VTable 是一个静态的、由编译器为每个类生成的数据结构，它本质上是一个函数指针数组。这个数组的每个条目都指向该类实现的虚函数（或从基类继承的虚函数）的实际入口点。

虚函数调用的流程：
当代码执行 object->virtualMethod() 时，实际的汇编指令序列大致如下：

  1. 从 object 的起始地址获取 vptr 的值（即 vptr = *(object)）。
  2. 通过 vptr 找到 VTable 的地址。
  3. 在 VTable 中，根据 virtualMethod 在虚函数表中的偏移量（这个偏移量在编译时确定），获取对应虚函数的指针。
  4. 通过这个函数指针，执行间接调用。

用伪汇编表示：

; 假设 object 的地址在 RAX 中
mov rbx, [rax]         ; rbx = *(rax)  => 获取 vptr (对象头部的第一个字段)
add rbx, offset_of_method ; rbx = rbx + offset => 获取 VTable 中虚函数的地址
call rbx               ; 间接调用虚函数

从这个流程可以看出，虚函数调用本质上就是一种间接调用。

B. 虚函数表劫持攻击 (VTable Hijacking)

虚函数表劫持是一种经典的内存破坏攻击，它利用程序中的漏洞（如堆溢出、Use-After-Free、格式化字符串漏洞等）来篡改对象的 vptr 或 VTable 本身，从而劫持程序的控制流。

攻击的原理主要有两种：

  1. 篡改 vptr 指针：

    • 攻击者通过内存破坏漏洞，修改一个对象的 vptr，使其不再指向该对象所属的合法 VTable。
    • 而是指向攻击者在内存中精心构造的一个伪造的 VTable。这个伪造的 VTable 中包含了攻击者希望执行的恶意代码（例如 shellcode）的地址，或者指向ROP gadget链的地址。
    • 当程序尝试调用这个被篡改对象的虚函数时，它会沿着伪造的 vptr 和 VTable 寻找函数指针，最终跳转到攻击者指定的恶意地址。

  2. 篡改 VTable 条目：

    • 攻击者找到一个合法的 VTable，并通过内存破坏漏洞，直接修改 VTable 中的某个函数指针条目。
    • 将该条目从指向原始的合法虚函数替换为攻击者控制的恶意地址。
    • 当程序正常调用该虚函数时，它会通过合法的 vptr 找到这个被篡改的 VTable，然后通过被修改的条目跳转到攻击者的恶意地址。

无论哪种方式，攻击者的最终目的都是让虚函数调用这个间接跳转，最终指向他们控制的非法地址，从而执行恶意代码。

C. CFG 对 VTable 劫持的防御

CFG 在这里发挥了关键作用。由于虚函数调用本质上是一种间接调用，它恰好落入了CFG的防护范围之内。

CFG 不关心 vptr 或 VTable 本身是否被篡改。CFG只关心最终的间接跳转目标地址是否合法。在编译器插入的 __guard_check_icall_stub 检查点，CFG会验证即将执行的虚函数调用的目标地址。

让我们分析一下 CFG 如何防御上述两种虚函数表劫持情景：

  1. 防御篡改 vptr 指向伪造 VTable 的攻击：

    • 攻击者构造的伪造 VTable 通常会包含指向 shellcode 或 ROP gadget 的地址。
    • 当程序尝试通过被篡改的 vptr 调用虚函数时，它会从伪造的 VTable 中获取一个地址作为跳转目标。
    • 在执行 call target_address 之前，CFG 检查会介入。它会询问操作系统：“这个 target_address 是一个合法的函数入口点吗？”
    • 由于攻击者提供的 shellcode 地址或 ROP gadget 地址，通常不会是程序编译时被CFG标记为合法函数入口点的地址（它们可能位于堆、栈或其他非代码段，或者即使在代码段内也不是任何函数的入口点）。
    • 因此，CFG 检查会失败，操作系统会立即触发 __fastfail 终止进程，从而阻止了攻击的发生。

  2. 防御篡改 VTable 中条目的攻击：

    • 攻击者直接修改了合法 VTable 中的一个函数指针，将其替换为恶意地址。
    • 当程序正常通过 vptr 找到这个被篡改的 VTable，并尝试调用被修改的虚函数时，它会从 VTable 中获取攻击者注入的恶意地址。
    • 同样，在执行间接调用之前，CFG 检查会验证这个恶意地址。
    • 由于这个恶意地址不是原始的合法虚函数入口点（已经被篡改了），也不是任何其他CFG认可的合法函数入口点，CFG 检查会失败。
    • 结果是进程被 __fastfail 终止，攻击被拦截。

关键点在于： CFG 的防御不是通过检测 vptr 或 VTable 是否被篡改，而是通过验证最终的间接跳转目标地址是否位于一个预先确定的“白名单”中。只要攻击者试图跳转到的地址不被CFG认为是合法的函数入口点，无论是通过伪造的VTable还是篡改的VTable条目，CFG都能够有效地阻止这次非法跳转。

D. 局限性与旁路 (Bypass) 技术 (简述)

尽管CFG提供强大的防护，但它并非完美无缺，也存在一些局限性，并可能被某些高级攻击技术绕过：

  1. ROP/JOP Gadgets 位于 CFG 合法目标中： 如果攻击者能够找到位于CFG标记的合法函数入口点列表中的 ROP/JOP gadget，那么CFG将无法阻止跳转到这些gadget。例如，如果一个gadget恰好是一个短函数的入口点，而这个函数又被CFG标记为合法，那么攻击者就可以利用它。这种情况下，攻击者需要进行信息泄露来获取这些合法gadget的地址。
  2. 粗粒度限制： CFG通常是页粒度的或函数入口粒度的。它不能阻止跳转到同一个合法函数内部的某个偏移量。如果攻击者能够找到一个位于合法函数内部的JOP gadget，并且能够通过某些方式跳转到该gadget，CFG可能无法检测到。
  3. 非CFG保护的模块： 如果一个进程中包含未启用CFG编译的模块（例如一些老旧的第三方库或系统模块），攻击者可能会利用这些未受保护的模块来执行间接调用或跳转，从而绕过CFG。
  4. 信息泄露： CFG本身并不阻止信息泄露。攻击者仍然可能通过各种漏洞获取内存布局信息，包括CFG合法目标的地址，从而辅助他们寻找可用的gadgets。
  5. 不防御所有类型的控制流劫持： CFG 主要防御前向边间接跳转和调用。对于后向边攻击（如纯粹的返回地址覆盖），Stack Canaries 或 Shadow Stacks 是更直接的防御。

尽管存在这些局限性，CFG仍然是防御现代控制流劫持攻击，特别是虚函数表劫持，一个非常有效的且性能开销较低的机制。它显著提高了攻击的难度和成本。

VI. CFG 的启用与配置

启用和配置CFG通常涉及编译器、链接器和操作系统的配合。

  1. 编译器选项：

    • 对于 Microsoft Visual C++ (MSVC)，您需要在项目属性中启用 /guard:cf 编译器选项。这会指示编译器在代码中插入CFG检查。
    • 例如，在命令行中：cl /guard:cf myprogram.cpp

  2. 链接器选项：

    • 链接器也需要 /guard:cf 选项来收集所有合法目标信息，并将其写入到最终的可执行文件中。
    • 例如，在命令行中：link /guard:cf myprogram.obj

  3. 操作系统支持：

    • CFG 需要 Windows 8.1 Update 3 或 Windows 10 及更高版本的操作系统支持才能在运行时执行验证。

  4. 应用程序清单 (Manifest)：

    • 为了确保操作系统知道一个可执行文件需要CFG保护，可以在应用程序的清单文件 (.manifest) 中显式指定。这通常由链接器自动完成，但也可以手动添加： 
      <assembly ...>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <controlFlowGuard>true</controlFlowGuard>
    </windowsSettings>
  </application>
</assembly>

  5. 进程强制启用：

    • 在企业环境中，管理员可以通过组策略或注册表为特定进程强制启用CFG，即使应用程序本身没有在清单中声明。这通常通过 Windows Defender Exploit Guard (或以前的 EMET) 来管理，以提供额外的保护层。

通过这些步骤，一个应用程序可以被编译并配置为在运行时受到CFG的保护。

VII. CFG 与其他安全机制的协同

CFG 并非孤立的安全机制，它与其他多种安全技术协同工作，共同构建一个多层次的纵深防御体系。

  1. DEP (Data Execution Prevention)： CFG 侧重于防止代码跳转到非法位置，而DEP则防止数据区域被执行。两者结合，使得攻击者既不能在数据区域执行shellcode，也不能轻易跳转到代码区域的任意位置。
  2. ASLR (Address Space Layout Randomization)： ASLR 增加了攻击者预测内存地址的难度，使得他们更难找到ROP/JOP gadgets的精确地址。CFG在此基础上，进一步确保即使攻击者知道地址，也只能跳转到CFG认可的合法入口点。
  3. Stack Canaries： 主要防御栈溢出，通过在栈上放置一个随机值来检测返回地址是否被篡改。CFG则专注于间接调用/跳转。两者互补，共同防御控制流劫持。
  4. Intel CET (Control-flow Enforcement Technology)： Intel CET 是一种硬件级别的 CFI 实现，它提供了比软件CFG更细粒度的保护和更低的性能开销。
    • Shadow Stacks (SS)： 针对后向边控制流（RET指令），在硬件层面维护一个独立的影子栈来存储返回地址。
    • Indirect Branch Tracking (IBT)： 针对前向边控制流（CALL/JMP指令），通过在目标地址处插入特殊的 END_BRANCH 指令来标记合法目标。只有当间接跳转到标记了 END_BRANCH 的地址时才被允许。
      CFG 可以被看作是软件实现的 Intel CET IBT 的前身或补充。在支持CET的硬件上，CET将提供更强的保护，但CFG仍然可以在没有CET硬件支持的系统上提供防护。
  5. 沙盒 (Sandboxing)： 沙盒机制通过限制进程的权限，即使攻击者成功劫持了控制流，也难以执行高权限操作或对系统造成严重破坏。

这些机制共同作用，使得攻击者需要克服更多的障碍才能成功执行攻击，从而大大提高了软件的整体安全性。

VIII. 性能考量

任何安全机制的引入都不可避免地会带来一定的性能开销。CFG 的设计者在性能和安全性之间寻求了平衡。

CFG 的性能开销主要来自于以下几个方面：

  1. 编译和链接时间： 编译器和链接器需要额外的时间来识别合法目标并插入检查代码。这通常是构建时的一次性开销，对运行时性能无影响。
  2. 运行时检查： 每次间接调用或间接跳转时，都需要额外执行一次 CFG 检查（调用 __guard_check_icall_stub）。这个检查涉及到对操作系统 API 的调用和对内存位图/列表的查询。
    • 页粒度检查的效率： 由于操作系统首先进行页粒度的检查，这是一个非常快速的操作。只有当页被标记为包含合法目标时，才可能进行更精细的地址匹配。
    • 缓存友好： CFG 位图通常是紧凑的，并且在内存中，有助于缓存命中。
    • Fast Fail 机制： 失败时直接终止进程，避免了后续不必要的执行。

根据微软的测试，CFG 对典型应用程序的性能影响通常在 0-2% 之间，对于大多数应用来说，这个开销是完全可以接受的。在某些I/O密集型或具有大量间接调用的场景下，开销可能会略高，但总体上仍然被认为是高效的。

IX. 未来展望

随着软件复杂性的增加和攻击技术的不断演进，控制流完整性将持续是安全领域的研究热点。

  • 硬件辅助 CFI 的普及： Intel CET 等硬件级CFI技术将逐渐普及，为操作系统和应用程序提供更强大的原生支持，实现更精细、更低开销的控制流完整性保护。
  • 更细粒度的软件 CFI： 研究人员仍在探索如何在软件层面实现更细粒度的CFI，例如通过类型安全CFI，确保间接调用只能跳转到具有兼容函数签名的目标。
  • 与机器学习的结合： 结合机器学习技术，实时分析程序行为，识别异常的控制流模式，从而发现和阻止未知的控制流劫持攻击。
  • 持续对抗新的攻击技术： 攻击者总会试图寻找绕过现有防御机制的方法。CFI 技术将需要不断演进，以应对新的攻击范式。

X. 深入防御控制流劫持的关键力量

Control Flow Guard (CFG) 作为一种重要的前向边控制流完整性技术，在Windows平台下显著提升了软件的安全性。它通过在编译时识别合法跳转目标并在运行时进行验证，有效地拦截了包括虚函数表劫持在内的多种控制流劫持攻击。理解并合理部署CFG及其他协同安全机制，是构建健壮安全软件体系的关键一环，为用户提供了更可靠的计算环境。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注