Primer on the OpenSSL “Heartbleed” Vulnerability

This is an older article I wrote somewhere else, but I felt that it might be helpful for people who wanted to learn a bit more about the vulnerability. While this is less of an issue now, it is the type of vulnerability that we could see again.

Heartbleed Logo — You know a vulnerability is serious if it has it’s own logo.

What is OpenSSL?
To understand this vulnerability you first need to know a bit about the technology behind it. OpenSSL is an Open source library that implements SSL and TLS. It is primarily used on Linux based servers that host web pages over HTTPS, but it is widely used overall throughout the world.

What is the vulnerability?
OpenSSL times sessions out after a certain period of time, so they have provided a heartbeat function that allows a client to keep the session open by asking the server to send data back to the client so that the connection stays active. If the client send sends a specifically crafted heartbeat request then the server can be tricked into sending random data from memory.

That’s kind of vague, I want to go deeper into the technical aspects. What is the actual vulnerability?
The heartbeat request is composed of a data payload and a payload length. The payload length can be up to 64 KB. When the server receives the request it is supposed to respond with the same data that was sent by the client. Unfortunately the server does not check the payload data versus the payload length.

So, if the client sends a request with no data in the payload, but also says that the payload is 64 KB, then the server will create a 64 KB variable that happens to contain data from RAM until it is overwritten with the payload. But since there is no payload the RAM is never overwritten. This variable is then sent back to the client.

What data could be obtained this way?
Unfortunately a lot of sensitive information is maintained in the RAM space available to OpenSSL. The most significant is that the private key that secures and encrypts the SSL session is maintained in RAM and could be revealed to an attack through this method. Additionally login information such as username and password for recent logins could be revealed this way.

But the attacker is just getting random information, how do they get what they want?
The attacker can keep sending heartbeat requests over and over again until they get the data that they are looking for. This data is sent in plaintext, so it is easy to review the results and parse out the data that they are looking for.

So, just patch the vulnerability and you are good right?
Not necessarily. There is no way to know what data has already been taken through this vulnerability. If an attacker has the private key from the server then that attacker can decrypt the session, which opens the way to impersonating the compromised website with a malicious site, or intercepting and decrypting data to secure websites. So any vulnerable site needs to upgrade OpenSSL, and request a new certificate, and install it.

Why should I care about all of this?
Many secure websites that you use across the internet could be vulnerable to this bug, in which case an attacker may have already obtained your username and password. You will want to change your password for sites that were vulnerable, but you don’t want to do it until they have patched the vulnerability on their servers. You should expect most major sites (banks, e-commerce sites, email services, etc) to send you a message if they were affected, and if they have resolved the vulnerability. If you receive such a notification it would be a good idea to change your password at that time.

I hope that this helps you understand what is going on with this vulnerability. You might notice that this has some similarities to Spectre/Meltdown in the way that it targets memory on the system. If you want to know more about Spectre and Meltdown, I plan to write something about that soon.