Recently, Intel made an exciting announcement regarding an anti-exploitation technology called Control-flow Enforcement Technology, or CET.  This builds on previous work on Control Flow Integrity (CFI) done by Microsoft researchers, as well as a paper by IAD researchers proposing hardware-enforced CFI.

While the IAD paper showed a modified Qemu and Linux kernel providing a proof-of-concept, an actual, in-silicon implementation in the major commodity CPU architecture would be a really big deal for trusted computing going forward.

A Brief History of the Exploitation Arms Race

For years, there has been an on-going arms race between attackers developing new exploitation techniques and security engineers developing exploit mitigation techniques to frustrate their attempts. CET is the natural evolution in this process.  The 30,000-foot view of how we got here so far can be summed up like this:

Exploit technique Mitigation technique(s)
Basic buffer overflow exploiting lack of bounds-checking in software. The attacker is able to over-write the return address of a function and take control over RIP/EIP. This allows the attacker to gain arbitrary code execution Stack protection technologies such as propolice, -f-stack-protector, etc., provide protection against simple buffer overflows
Advanced buffer overflow techniques allow an attacker to defeat stack protection Executable space protection like W^X, DEP, etc., prevent an attacker from writing their shell code into a buffer and then executing it
Return-to-libc attacks allow an attacker to take advantage of functions known to be in memory in certain locations to leverage library routine such as execve to bend to the attacker’s will Address-Space Layout Randomization (ASLR) and Position Independent Executables (PIE) make determining the runtime memory location of those helpful libc routines much more difficult for the attacker.
ASLR can be brute-forced and the attacker can still steer program execution Control Flow Integrity (CFI) can use a shadow stack to check against the return address in the main program’s execution flow to ensure that execution flow hasn’t been tampered with
CFI shadow stack is still in memory and can be corrupted by an attacker Hardware protection on the CFI shadow stack pages (CET).

Hardware-enforced CFI to the rescue

Control Flow Integrity is an obvious solution to the problems of an attacker corrupting data in memory to control program execution flow for malicious purposes.  However, a pure software CFI still has problems and could be exploited.  It is also not that widely supported.  The major problem is that if the CFI is implemented purely in software, only protected by the kernel’s protection mechanisms, then it isn’t really much safer than the memory space of the process being exploited.

NSA’s Information Assurance Directorate (IAD) proposed the natural solution to this: enforcement of CFI via hardware.  Essentially, the shadow stack would be in a region of memory that would be protected by either a modified MMU, or a new sort of chip like an MMU.  They modified the Qemu hypervisor to supply a simulation of such a chip, then modified the Linux kernel to work with this hardware.

Intel seems to be taking this to the next level, leveraging the MMU and building support into silicon, so that CFI can be enforced in hardware.

The shadow stack is placed in a region of memory inaccessible to the parent process and access is mediated via the MMU on behalf of the CPU.  The CPU checks the return address on ever RET against the address on the shadow stack, and if they don’t match, will throw an error.  Attempts by an attacker to access the shadow stack will result in a page fault, which will also need to be appropriately handled by the OS kernel.

CET and the future of the OSPP

Documents regarding the development of the Protection Profile for General Purpose Operating Systems have for a while referenced the IAD paper on hardware CFI.  Despite the theoretical proposals, there haven’t been “real” implementations. As Intel continues to flesh out their proposal and introduce support, I foresee future revisions of the PP taking this as an objective requirement.  It will take some time for competing CPU architecture manufacturers to implement similar functionality before it can be made a hard requirement, however.

That said, I see this is a natural evolution of exploit mitigation techniques and really the future of trusted computing.  CET combined with boot chain trust, application white listing and existing/new anti-exploitation techniques put us on track to developing trusted systems for which even more classes of threat can be eliminated.