A Technical Look at Intel’s Control-flow Enforcement Technology

Intel Fellow Client Computing Group
 

Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections. Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known as JOP) are two such techniques that has been gaining popularity. JOP or ROP attacks can be particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.

ROP is where the attacker relies on RET (return) instruction to stitch together a malicious code flow that was not programmer-intended. Per the design, return instructions fetch the address of next instruction from stack (which was pushed on the stack by the prior CALL instruction) and executes instructions from that address. In the case of ROP-based attacks, the attacker apriori or at runtime scans for sequence of bytes in existing program code by scanning the program on disk or in memory. Figure 1 shows an example of existing instruction stream.


Figure 1

Example of existing instruction stream.

This example shows three instructions executed in a sequence (notice there are no RET instructions in this programmer-intended sequence) and corresponding bytes of program in blue boxes below. The same set of code bytes, when interpreted starting at an invalid offset, can also mean alternate set of instructions that cause the sequence to end with a RET as shown in the figure below where bytes in red boxes correspond to a different instruction sequence and in this example, each instruction is followed by C3 which corresponds to the return instruction. These instruction sequences are called “gadgets”.


Figure 2

Gadget instruction sequence

 
By carefully placing starting addresses of these alternate instruction-sets or “gadgets” that are all terminated by the ret instruction, the attacker can execute arbitrary attack code flows that were not intended in the original program using already-executable bytes of the original program. So, with a ROP attack, the attacker can execute arbitrary code composed via gadgets using the existing program inheriting all the permissions of the program. This makes these attacks effective and hard to detect and potentially allow an attacker to escalate privileges or break out of process sandboxes. These types of malware target operating systems (OS), browsers, readers and many other applications, and it takes deep integration with hardware at the foundation to deliver more effective protection with minimal performance impact.
 
Since ROP relies on RET instructions, where the address of the next instruction to execute is fetched from a stack, stack corruption plays a critical role in ROP attacks. CET enables the OS to create a Shadow Stack, which is designed to be protected from application code memory accesses, and stores CPU-stored copies of the return addresses. This helps ensure that even when an attacker is able to modify/corrupt the return addresses in the data stack for the purpose of carrying out a ROP attack, the attacker is not able to modify the Shadow Stack, and the CET state machine in the CPU detects mismatches between the address on the shadow and data stack to help prevent the attack via an exception reported to the OS.

Similarly, other indirect branch instructions, such as Call and Jump indirect can be used to launch variant attacks - called COP (call oriented programming) or JOP (jump oriented programming). CET also adds an Indirect Branch Tracking capability to provide software the ability to restrict COP/JOP attacks.


Intel has been actively collaborating with Microsoft and other industry partners to address control-flow hijacking by using Intel’s CET technology to augment the previous software-only control-flow integrity solutions. Intel’s CET, when used properly by software, is a big step in helping to prevent exploits from hijacking the control-flow transfer instructions. For more details, reference Microsoft’s BLOG “Understanding Hardware-enforced Stack Protection”.

 

REFERENCE LINKS

Security Analysis of Processor Instruction Set Architecture for Enforcing Control-Flow Integrity (ACM Digital Library):
https://dl.acm.org/doi/10.1145/3337167.3337175

Paper PDF: https://dl.acm.org/doi/pdf/10.1145/3337167.3337175


Intel Software Development Emulating (SDE):
https://software.intel.com/content/www/us/en/develop/articles/emulating-applications-with-intel-sde-and-control-flow-enforcement-technology.html

Intel Compiler:
https://software.intel.com/content/www/us/en/develop/articles/intel-c-compiler-180-for-linux-release-notes-for-intel-parallel-studio-xe-2018.html

GCC Instrumentation Options:
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Instrumentation-Options.html#Instrumentation-Options

Linux Kernel Patches:
https://lkml.org/lkml/2020/4/29/1364
https://www.phoronix.com/scan.php?page=news_item&px=Intel-CET-2020-WIP

Product and Performance Information

1

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804