Heartbleed bug: How it works and how to avoid similar bugs

The Heartbleed bug is a vulnerability in open source software that was first discovered in 2014. Anyone with an internet connection can exploit this bug to read the memory of vulnerable systems, leaving no evidence of a compromised system.

Heartbleed is an implementation bug (CVE-2014-0160) in the OpenSSL cryptographic library. OpenSSL is the most popular open source cryptographic library (written in C) that provides Secure Socket Layer (SSL) and Transport Layer Security (TLS) implementation to encrypt traffic on the internet. Even though the bug is in the OpenSSL library, it has nothing to do with the SSL/TLS protocols. The vulnerability is in the OpenSSL code that handles the Heartbeat extension (RFC 6520) for TLS/DTLS.

OpenSSL versions 1.0.1 through 1.0.1f are vulnerable unless compiled with the uncommon -DOPENSSL_NO_HEARTBEATS option. The earliest non-vulnerable version is 1.0.1g.

How does the Heartbleed bug work?

The Heartbleed bug got its start from improper input validation in the OpenSSL implementation of the TLS Heartbeat extension. Due to the missing bounds check on the length and payload fields in Heartbeat requests, coupled with trusting the data received from other machines, the responding machine mistakenly sends back its own memory data.

During a TLS encrypted handshake, two machines send each other Heartbeat messages. According to RFC 6520, a Heartbeat response needs to contain the exact copy of the payload from the Heartbeat request. When a Heartbeat request message is received, the machine writes the payload contents to its memory and copies the contents back in response. The length field is meant to be the length of the payload. OpenSSL allocates memory for the response based on length and then copies the payload over into the response using memcpy().

Attackers can send Heartbeat requests with the value of the length field greater than the actual length of the payload. OpenSSL processes in the machine that are responding to Heartbeat requests don’t verify if the payload size is same as what is specified in length field. Thus, the machine copies extra data residing in memory after the payload into the response. This is how the Heartbleed vulnerability works. Therefore, the extra bytes are additional data in the remote process’s memory.

What is the impact of Heartbleed?

The Heartbleed bug allows anyone on the internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. Sensitive information such as session identifiers, usernames, passwords, tokens, and even the server’s private cryptographic keys, in some extreme cases, can be extracted from the memory. To make matters worse, this attack leaves no apparent evidence in the log files. Thus, it is extremely difficult to determine whether the machine has been compromised.

An attacker can read 64 kilobytes of server memory for a single Heartbeat message. However, there is no limit to the amount of memory that can be read from a vulnerable server. Furthermore, an attacker can continue reconnecting and requesting an arbitrary number of 64-kilobyte segments to reveal secrets (passwords, secret keys, credit card numbers, etc.) stored in memory.

Could it have been avoided?

The problem could have been avoided by validating the message length and ignoring Heartbeat request messages asking for more data than their payload needs. A security review of OpenSSL software could have also caught the Heartbleed bug.

What lessons can we learn from the Heartbleed bug?

Heartbleed is a simple bug to remediate. To prevent sensitive data leakage through Heartbleed, upgrade to the latest stable version of OpenSSL. Don’t blindly trust the software—it’s also best to integrate security programs into software development.