Welcome to the Acumen Security Blog

Intel RIP ROP, Hardware-Enforced CFI, and the Future of Trusted Computing

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.


The Mostly Forgotten USB Drive PP

The oldest Protection Profile (PP) currently on NIAP’s approved PP list is also one that has not gotten much attention. The Protection Profile for USB Flash Drives was approved in December of 2011 but in the nearly half-decade since its approval no successful evaluations have been performed against it. It is interesting to take a look at this largely forgotten PP and it may be worth it for vendors with compliant products to consider the benefits of certification in the future.

The USB PP was written for USB flash drives which encrypt data with an onboard processor. AES is the only encryption algorithm which is allowed. While most of the PP’s encryption requirements will be familiar to anyone who was worked in CC it does contain an unusual key masking requirement in FCS_COP.1(4). The purpose of that SFR is to ensure that the Data Encryption Key (DEK) used to encrypt the data stored on the TOE is masked by a Key Encryption Key (KEK). Similar requirements are found in newer PPs for encrypted data storage products such as the Full Drive Encryption cPP but the USB PP’s requirements are more proscriptive.

One of the USB PP’s most obvious weaknesses is its very basic authentication requirements. Split authentication factors are optional and the use of a password is the only mandatory requirement. The PP does not require any specific minimum password length. This is acknowledged as a weakness in an application note for FCS_CKM.1(3) but is accepted because of perceived convenience. There is nothing preventing a TOE from implementing stronger password requirements, but PP conformance is possible without any meaningful password strength enforcement mechanism. The PP does contain an assumption that users will follow guidance on strong password creation but real-world experience has shown that this is probably not realistic if the TOE is to be deployed on a large scale.

The USB PP’s non-cryptographic SFRs focus on self-tests, user authorization and the prevention of malware distribution by the TOE. Unsurprisingly considering the nature of the TOE there are no audit requirements, nor are there any requirements for individual user identification.

Even though the USB PP has fallen by the wayside it is still a NIAP-approved PP with no current planned sunset date. Vendors who make FIPS-approved encrypted flash drives should keep in mind that it may take relatively little effort to get their products CC certified as well. The data encryption assurance activities for this PP are drawn directly from CAVP tests and any product which meets FIPS 140-2 self-test requirements will satisfy the self-test requirements of this PP. A vendor will have to determine for themselves if CC certification would give them a competitive advantage, but the USB PP is still available should anyone decide that they are in the market.