About Heartbleed, Memory Safety, CRASH/SAFE, HardBount/Watchdog, miTLS, and Everything Else

Heartbleed exploits a memory safety violation. One can break up such violations in many ways: spatial vs. temporal violations, control flow hijacking vs. no control data-only attacks, and for data-only attacks data corruption vs. data leaks. Heartbleed is a confidential data leak caused by a spatial memory violation (an out of bounds read). Here is a breakdown of memory safety violations and how Heartbleed fits in the rest of the picture:

The kind of memory safety they break:

  • spatial violations (aka. buffer overflows)
    • out of bounds write (stack and heap overflows)
    • out of bounds read <– Heartbleed
  • temporal violations
    • use after free (dangling pointers)
    • invalid free (e.g. double free)

The way they are exploited:

  • control flow hijacking
    • code injection
    • jump/return to libc
    • return-oriented programming
  • no control data-only attacks
    • data corruption
    • confidential data leaks <– Heartbleed

Memory safety violations and the corresponding vulnerabilities are a consequence of decades old security-performance trade-offs in current system and architecture designs. Current hardware and most operating systems and programming languages provide no effective and comprehensive protection against these attacks, and programmers are left having to worry about memory safety in every single line of low-level code they write (the Heartbleed bug and fix were in fact only a couple of lines long). At the hardware level, backwards compatibility is deemed more important than security, and at the software level (operating system and programming languages) efficiency and to a certain extend also backwards compatibility trumps security. This leaves lots of critical vulnerabilities in any large piece of low-level software.

In a way the Heartbleed bug is a relatively trivial programming error. What makes it so catastrophic is that it appeared in a software component that is so widely used and so crucial for security (OpenSSL had access to the web servers' private signing keys), while at the same time leaving no trace in server logs. The fact that the error is so simple to even explain in a comic means that black hats will have no problem whatsoever to reliably exploit this vulnerability in unpatched servers (assuming they weren’t doing this already). They are in fact currently exploiting memory safety vulnerabilities that are orders of magnitude harder to exploit (and which don’t stop at leaking data but give them full control of the attacked machine). For them Heartbleed is a huge amount of very low hanging fruit.

The Heartbleed bug also shows that the currently deployed defenses for stopping memory safety attacks are very incomplete and insufficient. These incomplete defenses are generally targeted only at control flow hijacking exploiting spatial violations, which means that many of the attacks nowadays are data-only (like Heartbleed) or exploit temporal violations (use after free and double free bugs are very popular in the recent Pawn2Own competitions). More comprehensive protections are needed.

CRASH/SAFE

I’m currently involved with CRASH/SAFE, a research project aimed at designing a significantly more secure computer system from scratch. Because memory safety vulnerabilities are so prevalent in current systems the CRASH/SAFE system has comprehensive hardware and system mechanisms for completely stopping all such violations, as well as orthogonal protection mechanisms that would have also stopped the Heartbleed attack. One thing to keep in mind though is that CRASH/SAFE is a long-term clean-slate research effort, not targeted at direct immediate adoption.

(1) Low-Fat Pointers for Spatial Memory Safety

Low-fat pointers [1] are the mechanism that most directly targets spatial memory safety violations. By default it would have been the mechanism stopping Heartbleed, but (2) and (3) could have also saved the day.

We enforce spatial memory safety by inseparably associating bounds with every pointer and checking these bounds on every memory access. Dedicated checking hardware runs in parallel with the processor’s normal datapath so that the checks do not slow down processor operation (0% runtime overhead). To achieve the safety of fat pointers without increasing program state, we compactly encode approximate base and bound pointers along with exact address pointers for a 46b address space into one 64-bit word with a worst-case memory overhead of 3%.

(2) The Tag Management Unit with Memory Safety Micro-Policy

SAFE includes a programmable tag management unit that can be programmed to prevent all spatial and temporal memory safety violations [2]. While this is not needed on the SAFE machine because low-fat pointers (point 1) and garbage collection [3] already solve the memory safety problem in SAFE, this mechanism can be applied to legacy systems. We are in fact currently working on bringing this solution to more mainstream systems. While convincing hardware companies to implement this is a different story, there is some hope that comprehensive memory safety solutions like these will make it into future processors (see note on Intel MPX and HardBound/WatchDog below).

(3) The Tag Management Unit with Taint Tracking / IFC Micro-Policy

The Heartbleed attack was using a tainted index to access an array. Then it was sending classified data over the wire. Both of these operations would have been stopped by the taint tracking / information flow control mechanism in SAFE [4].

Intel MPX and HardBound/WatchDog

There is some hope that more comprehensive memory safety solutions will make it into future processors. For instance Intel is adding something called Memory Protection Extensions (MPX) [5] to its next generation processors. While these hardware extensions only target spatial violations, won’t be available until 2015(?), and it will probably take a long time for software to start using them afterwards, it is still very encouraging to see Intel attacking the memory safety problem heads on.

This defense mechanism seems to be quite similar in its low-level details to the HardBound/WatchDog [6,7] line of research at University of Pennsylvania. So research seems to be having some impact on all this, albeit a rather indirect one.

miTLS

My colleagues in the Prosecco team at INRIA have more direct involvement with SSL/TLS since they are developing a more secure variant called miTLS [8]. By using the memory safe language F#, miTLS should be much better protected against Heartbleed-like attacks. On the other hand, the safety of F# (and similar languages) doesn’t come without a performance cost, one which could be much lower if the hardware would provide support for memory safety.

References

[1] Low-Fat Pointers: Compact Encoding and Efficient Gate-Level Implementation of Fat Pointers for Spatial Safety and Capability-based Security. By Albert Kwon, Udit Dhawan, Jonathan M. Smith, Thomas F. Knight, Jr., and André DeHon. In proceedings of the 20th ACM Conference on Computer and Communications Security (CCS), November 4-8, 2013, Berlin, Germany.

[2] Micro-Policies: Formally Verified Low-Level Tagging Schemes for Safety and Security. Catalin Hritcu. Online Note, September 2013.

[3] Hardware Support for Safety Interlocks and Introspection. Udit Dhawan, Albert Kwon, Edin Kadric, Cătălin Hriţcu, Benjamin C. Pierce, Jonathan M. Smith, Gregory Malecha, Greg Morrisett, Thomas F. Knight, Jr., Andrew Sutherland, Tom Hawkins, Amanda Zyxnfryx, David Wittenberg, Peter Trei, Sumit Ray, Greg Sullivan, and André DeHon. SASO2012 Adapative Host and Network Security Workshop, September 14, 2012.

[4] A Verified Information-Flow Architecture. Arthur Azevedo de Amorim, Nathan Collins, André DeHon, Delphine Demange, Cătălin Hriţcu, David Pichardie, Benjamin C. Pierce, Randy Pollack, and Andrew Tolmach. In 41st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), pages 165-178. ACM, January 2014.

[5] Introduction to Intel Memory Protection Extensions (MPX). For details about the Intel MPX instructions, see the Intel Architecture Instruction Set Extensions Programming Reference.

[6] Hardware-enforced Comprehensive Memory Safety. Santosh Nagarakatte, Milo M K Martin and Steve Zdancewic. IEEE MICRO’s “Top Picks of Architecture Conferences of 2012” Issue (Micro Top Picks’2013) May/June 2013.

[7] Practical Low-Overhead Enforcement of Memory Safety for C Programs. Santosh Nagarakatte. PhD Dissertation, University of Pennsylvania, November 2012.

[8] miTLS — a verified reference implementation of the TLS protocol.

Advertisements

One Response to About Heartbleed, Memory Safety, CRASH/SAFE, HardBount/Watchdog, miTLS, and Everything Else

  1. I am proud of your efforts. I never made it to the point that I could even think about anything else, and I was told today – with my back – no more ru Click https://twitter.com/moooker1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: