Heartbleed

Heartbleed is a critical vulnerability in OpenSSL, disclosed in April 2014, that let an attacker read chunks of a server’s memory straight off the wire.

OpenSSL is the library a very large part of the internet uses to implement TLS, the protocol behind HTTPS and behind secure mail delivery. The flaw was not in the protocol: it was in one particular implementation of the heartbeat extension, which exists so that two ends of a connection can check that the other is still there.

A request said how many bytes it wanted echoed back. The code trusted that number instead of checking it against the data actually sent, so a short request that claimed to be long was answered with whatever happened to sit next to it in memory.

Why it was so serious

It leaked memory, and memory holds secrets. What came back was not a file an attacker had asked for: it was whatever the process had recently handled. In practice that meant session data, credentials in transit, and in the worst case the server’s own private key.

It was silent. A Heartbleed request looks like a heartbeat request, because it is one. It did not crash anything, it left no obvious trace in application logs, and it could be repeated for as long as the attacker wanted.

It was everywhere. Because OpenSSL sits under so much other software, the affected estate was not one product but web servers, mail servers, VPN appliances, embedded devices and anything else that had linked against a vulnerable version.

Patching was not the end of it. If the private key of a certificate might have leaked, updating the library is only half the work: the certificate has to be reissued and the old one revoked, and anything that was in memory during the exposure window has to be treated as known to somebody else.

A worked example

A site terminates HTTPS with a vulnerable version of the library.

An attacker sends the malformed heartbeat and gets back a block of the server’s memory. They repeat it, thousands of times, collecting whatever passes through.

Among those blocks is the private key of the server’s certificate. From that point the attacker can impersonate the site to anyone they can place themselves in front of, and can decrypt captured traffic that was protected by that key.

Nothing on the server looks wrong. The service never went down, and the requests were valid.

Where this shows up in an audit

Heartbleed is old, and the reason it is still worth a glossary entry is not nostalgia. It is the cleanest example of a class of problem that keeps recurring: the risk you inherit from a library you never chose, and the difference between “we applied the patch” and “we assumed the secrets were gone”. The second question is the one that gets skipped, and it is the one that decides whether an exposure actually ended.