Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Apr 8 '14 at 12:44

This question came from our site for software developers, mathematicians and others interested in cryptography.

This video explanation is pretty good – binaryanomaly Apr 9 '14 at 11:19
Another useful blog article addressing the Heartbleed bug can be found here:… It also gives the steps to upgrade OpenSSL on CentOS and Ubuntu. – user43873 Apr 9 '14 at 14:50
Zulfikar Ramzan (CTO of cloud security firm Elastica) made this video, which does a great job of explaining the bug at a pretty high level. He also does a lot of videos for Khan Academy. Vimeo: OpenSSL Heartbeat (Heartbleed) Vulnerability (CVE-2014-0160) and its High-Level Mechanics Thanks to Greg Kumparak of TechCrunch for the link. – EddieN120 Apr 10 '14 at 4:09
I was just curious about how the exploit works and video explains that perfectly, you should definitely check it out. – PSIXO Apr 10 '14 at 9:26
Latest xkcd has a simple explaination: – Paddy Apr 11 '14 at 7:46
up vote 235 down vote accepted

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.


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.

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

share|improve this answer
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 Apr 8 '14 at 13:27
@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 Apr 8 '14 at 13:38
@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 Apr 8 '14 at 14:47
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 Apr 8 '14 at 17:17
@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 Apr 9 '14 at 10:00

protected by Community Apr 10 '14 at 10:12

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.