Heartbleed: The 2014 OpenSSL Bug That Leaked Server Memory

On 7 April 2014, a bug in OpenSSL, the open-source library that secured a large share of the web, became public, together with a logo and a catchy name: Heartbleed. It allowed anyone on the internet to read pieces of memory from affected servers, without leaving an obvious trace. It was one of the most widely discussed security flaws in the history of the web.

What the bug was

Heartbleed was identified as CVE-2014-0160. It was located in the heartbeat extension of OpenSSL, a feature that lets one side of an encrypted connection check that the other is still there. A client sends a small message and says how long it is, and the server sends the same data back. The flaw was a missing length check: a client could claim that its message was long while sending only a few bytes, and the server would reply with the data it held in the memory next to it.

Each request could return up to 64 kilobytes of memory. An attacker could repeat the request again and again, and what came back could include usernames and passwords, session cookies, private data and potentially even the server's private encryption keys.

Who found it, and which versions were affected

The bug was found independently by Neel Mehta of Google's security team and by engineers at the Finnish security firm Codenomicon. It affected OpenSSL versions 1.0.1 through 1.0.1f. The flawed code first shipped in a release in March 2012 and had gone unnoticed for about two years. OpenSSL 1.0.1g, which fixed the issue, was released at the time of disclosure. Versions in the 1.0.0 and 0.9.8 branches were not affected.

Why it was so serious

• Wide use. OpenSSL was running on web servers, email servers, VPN appliances and many other devices.
• No trace. Exploitation usually left no entry in ordinary logs, so owners could not tell if they had been targeted.
• Keys at risk. If a private key was exposed, an attacker could potentially impersonate the site or decrypt recorded traffic.

There were real-world consequences. The Canada Revenue Agency reported that about 900 social insurance numbers were stolen through the bug and temporarily shut down its online services, and a man was later charged in connection with the theft. Security researchers also reported that a theft of data on roughly 4.5 million patients at the hospital operator Community Health Systems began with an attack that used the flaw.

The clean-up checklist

Heartbleed became the standard example of a full response:

1. Upgrade OpenSSL to a fixed version, or apply the vendor's patch.
2. Revoke the old certificate and issue a new one with a new private key, since the old key might have leaked.
3. Restart services so they load the updated library.
4. Ask users to change passwords, and invalidate existing sessions.

Many sites patched quickly, but a large share did not replace their certificates afterwards, and surveys in the weeks afterwards showed that a considerable number of servers remained vulnerable for some time.

A boost for open source funding

Heartbleed also drew attention to the fact that a critical piece of internet infrastructure had been maintained by a small team with limited resources. The Linux Foundation launched the Core Infrastructure Initiative in 2014 to fund important open-source projects, and OpenSSL received more support. A fork called LibreSSL was also started by the OpenBSD project.

How the web responded

The reaction to Heartbleed was fast by the standards of the time. Large providers patched within hours or days, and many posted notices telling users whether they had been affected and whether they should change passwords. A number of websites published lists of services and their status, so that users could see which ones needed attention. Security researchers built tools that allowed anyone to test whether a given server was vulnerable.

The response was not perfect. Some organisations told users to change passwords before they had patched their own servers, which meant new passwords could be exposed straight away. The sensible order is to fix the server first, replace certificates second, and only then ask users to reset their credentials.

That sequencing is a good rule for any incident: stop the leak before you refresh the secrets, otherwise you may be giving the attacker the new ones. It is also a reason to keep a short written checklist ready, so that the order is not improvised under pressure.

Was anyone exploiting it before the announcement?

This remains a question with only a partial answer. Some reports suggested that attacks might have occurred before public disclosure, but evidence for specific cases was limited and debated. Because exploitation left few traces, the safe assumption for any affected server was that its secrets could have been read, and a full rotation was the recommended course.

The practical lesson for site owners

You rarely control the libraries underneath your hosting, so choose a provider who updates them promptly, and make sure your own software stack is current. If you ever learn that a server your site relied on was exposed, assume secrets may have leaked: replace certificates, rotate passwords and API keys and sign out all sessions.

Free, easily renewed certificates make rotation painless; see our SSL page for how it works, and our knowledge base for step-by-step guides.