Intel Releases New Technology Specifications to Protect Against ROP attacks

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 are 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.

Intel and Microsoft recognized the seriousness of ROP attacks as well as the difficulty in developing the means to protect from ROP/JOP. Together, we considered over ten technology innovations to address these emerging threats over last 7 years and narrowed it down to the CET specification for x86/x64 architecture to make significant advances in addressing the ROP threat. Based on prior experience with defining instruction set extensions, and enabling challenges associated with a new ISA, we set goals to have an ISA for ROP/JOP prevention that is transparent to most well designed/implemented software requiring minimal to no changes; yet allow opt out capability for SW that requires changes. We also wanted to make sure that the solution is applicable to not just applications, but also to operating system kernels, and is beneficial to SW written using most programming languages. We also wanted to ensure that software enabled for CET works on legacy platforms without changes (albeit with no security benefits). Finally, and most importantly, we wanted to address all known ROP/JOP attacks.

While we include a brief description of CET here, there is no substitute for careful reading of the complete specification. Here we highlight two key aspects of ISA to get you started, namely, shadow stack and indirect branch tracking. It is the combination of these two that are designed to address both ROP and JOP class of attacks.

CET defines a second stack (shadow stack) exclusively used for control transfer operations, in addition to the traditional stack used for control transfer and data. When CET is enabled, CALL instruction pushes the return address into a shadow stack in addition to its normal behavior of pushing return address into the normal stack (no changes to traditional stack operation). The return instructions (e.g. RET) pops return address from both shadow and traditional stacks, and only transfers control to popped address if return addresses from both stacks match. There are restrictions to write operations to shadow stack to make it harder for adversary to modify return address on both copies of stack implemented by changes to page tables. Thus limiting shadow stack usage to call and return operations for purpose of storing return address only. The page table protections for shadow stack are also designed to protect integrity of shadow stack by preventing unintended or malicious switching of shadow stack and/or overflow and underflow of shadow stack.

The ENDBRANCH instruction is a new instruction added to ISA to mark legal target for an indirect branch or jump. Thus if ENDBRANCH is not target of indirect branch or jump, the CPU generates an exception indicating unintended or malicious operation. This specific instruction has been implemented as NOP on current Intel processors for backwards compatibility (similar to several MPX instructions) and pre-enabling of software.

As we have in the past, Intel strives to minimize performance impact of security features, CET being no except, however, please keep in mind that performance impact is highly dependent on specific software and workload.

Finally, we want to recognize that this specification has benefited from extensive collaboration with Microsoft.

For more complete information about compiler optimizations, see our Optimization Notice.