225

I've been hearing more about the OpenSSL Heartbleed attack, which exploits some flaw in the heartbeat step of TLS. If you haven't heard of it, it allows people to:

  • Steal OpenSSL private keys
  • Steal OpenSSL secondary keys
  • Retrieve up to 64kb of memory from the affected server
  • As a result, decrypt all traffic between the server and client(s)

The commit to OpenSSL which fixes this issue is here

I'm a bit unclear - everything I've read contains information about what one should do about it, but not how it works. So, how does this attack work?

Improve this question
5

1 Answer 1

Reset to default
249

This is not a flaw in TLS; it is a simple memory safety bug in OpenSSL.

The best explanations I've run across so far are the blog posts Diagnosis of the OpenSSL Heartbleed Bug by Sean Cassidy and Attack of the week: OpenSSL Heartbleed by Matthew Green.

In short, Heartbeat allows one endpoint to go "I'm sending you some data, echo it back to me". You send both a length figure and the data itself. The length figure can be up to 64 KiB. Unfortunately, if you use the length figure to claim "I'm sending 64 KiB of data" (for example) and then only really send, say, one byte, OpenSSL would send you back your one byte -- and 64 KiB (minus one) of other data from RAM.

Whoops!

This allows the other endpoint to get random portions of memory from the process using OpenSSL. An attacker cannot choose which memory, but if they try enough times, their request's data structure is likely to wind up next to something interesting, such as your private keys, or users' cookies or passwords.

None of this activity will be logged anywhere, unless you record, like, all your raw TLS connection data.

Not good.

https://xkcd.com/1354/

The above xkcd comic does a nice job illustrating the issue.

Edit: I wrote in a comment below that the heartbeat messages are encrypted. This is not always true. You can send a heartbeat early in the TLS handshake, before encryption has been turned on (though you're not supposed to). In this case, both the request and response will be unencrypted. In normal usage, heartbeats ought to always be sent later, encrypted, but most exploit tools will probably not bother to complete the handshake and wait for encryption. (Thanks, RedBaron.)

Improve this answer
32
  • 34
    memcpy with an unchecked length-parameter supplied by the user - one of the most common security-mistakes in C. It's a sad miracle that this wasn't noticed for so long in a software so widely deployed as OpenSSL.
    – Philipp
    Commented Apr 8, 2014 at 13:27
  • 43
    @Philipp It wasn't noticed and reported until now. It's plausible that sharp-eyed intelligence agencies have been exploiting it for the last two years.
    – Matt Nordhoff
    Commented Apr 8, 2014 at 13:38
  • 28
    @ArunMu Yes, it will be encrypted. You can rest assured that attackers will be downloading your RAM securely. :-P Except from other attackers who have already stolen your keys.
    – Matt Nordhoff
    Commented Apr 8, 2014 at 14:47
  • 16
    While it is not a flaw in the TLS extention or the TLS protocol, the TLS specification is still somewhat responsible. The layering of messages inside records and the fact that you typically have multiple length specifications inside those records as a very fragile protocol design and asks for trouble. Even worse when implementations do not abstract the segmentation and parsing away with safe helper methods (so all extension parsers need to reinvent the wheel).
    – eckes
    Commented Apr 8, 2014 at 17:17
  • 9
    @RedBaron Mid-air collision! The RFC says a heartbeat "SHOULD NOT" be sent during the handshake and that the receiver "SHOULD" drop it. An implementation is allowed to disobey a "SHOULD" -- otherwise it would be a "MUST".
    – Matt Nordhoff
    Commented Apr 9, 2014 at 10:00

You must log in to answer this question.