Control-flow integrity

Google has shipped Android with the Linux kernel compiled by Clang with link-time optimization (LTO) and CFI since 2018.[12]

Intel Control-flow Enforcement Technology (CET) detects compromises to control flow integrity with a shadow stack and indirect branch tracking.[13][14]

The shadow stack stores a copy of each CALL in a specially-protected shadow stack and on a RET, checks if the return address stored in the normal stack and shadow stack are equal. If the addresses are not equal, the processor generates an INT #21 (Control Flow Protection Fault).

Indirect branch tracking attempts to detect calls to unauthorized indirect JMP or CALL targets. It was implemented by modifying the behavior of indirect JMP and CALL instructions so that they also set an internal state machine from IDLE to WAIT_FOR_ENDBRANCH and placing a new ENDBRANCH instruction, which changes the internal state machine from WAIT_FOR_ENDBRANCH to IDLE, at the beginning of every authorized indirect JMP or CALL target. If the processor is in a WAIT_FOR_ENDBRANCH state (meaning, the previous instruction was an indirect JMP or CALL), and the next instruction is not an ENDBRANCH instruction, the processor generates an INT #21 (Control Flow Protection Fault).

Control Flow Guard (CFG) was first released for Windows 8.1 Update 3 (KB3000850) in November 2014. Developers can add CFG to their programs by adding the /guard:cf linker flag before program linking in Visual Studio 2015 or newer.[15]

As of Windows 10 Creators Update (Windows 10 version 1703), the Windows kernel is compiled with CFG.[16] The Windows kernel uses Hyper-V to prevent malicious kernel code from overwriting the CFG bitmap.[17]

CFG operates by creating a per-process bitmap, where a set bit indicates that the address is a valid destination. Before performing each indirect function call, the application checks if the destination address is in the bitmap. If the destination address is not in the bitmap, the program terminates.[15] This makes it more difficult for an attacker to exploit a use-after-free by replacing an object's contents and then using an indirect function call to execute a payload.[18]

For all protected indirect function calls, the _guard_check_icall function is called, which performs the following steps:[19]

1. Convert the target address to an offset and bit number in the bitmap.
   1. The highest 3 bytes are the byte offset in the bitmap
   2. The bit offset is a 5-bit value. The first four bits are the 4th through 8th low-order bits of the address.
   3. The 5th bit of the bit offset is set to 0 if the destination address is aligned with 0x10 (last four bits are 0), and 1 if it is not.
2. Examine the target's address value in the bitmap
   1. If the target address is in the bitmap, return without an error.
   2. If the target address is not in the bitmap, terminate the program.

There are several generic techniques for bypassing CFG:

• Set the destination to code located in a non-CFG module loaded in the same process.[18][20]
• Find an indirect call that was not protected by CFG (either CALL or JMP).[18][20][21]
• Use a function call with a different number of arguments than the call is designed for, causing a stack misalignment, and code execution after the function returns (patched in Windows 10).[22]
• Use a function call with the same number of arguments, but one of pointers passed is treated as an object and writes to a pointer-based offset, allowing overwriting a return address.[23]
• Overwrite the function call used by CFG to validate the address (patched in March 2015)[21]
• Set the CFG bitmap to all 1's, allowing all indirect function calls[21]
• Use a controlled-write primitive to overwrite an address on the stack (since the stack is not protected by CFG) [21]