There’s been a lot of digital ink spilled over the past few days regarding the so-called “Heartbleed” bug. The bug should not be confused with a computer virus, which is a malicious program designed to steal or otherwise harm a computer system that may or may not use a security flaw to allow it to do its dirty work. While calling it a virus may make more sense to end users, it’s also misleading sensationalism. So now that we have that out of the way, let’s talk about how SSL (which stands for Secure Sockets Layer) actually works in relation to “Heartbleed”, what systems are affected, and what it all means for end users and developers.
SSL Keep-Alive or Heartbeat Requests
SSL is a cryptographic protocol that provides end-to-end security for packets sent over computer networks. It’s end-to-end in that after there’s an initial request (called a handshake) to the remote server by the client to agree on a “key”, all future traffic is encrypted. Wikipedia has a great description here: Secure Sockets Layer
Anyway, once the SSL channel is established with the remote server, the client and server can communicate in a secure fashion that is not easily defeated. Each package of communication is encrypted from the moment it leaves the client until the moment it reaches the server and vice versa.
However, the starting and restarting an SSL channel is relatively time- and resource-intensive. A lot of messages have to go back and forth as part of the handshake before the actual content can be delivered. While all of this happens in milliseconds, that’s a lot of time to a computer and as a result the connection can timeout if enough time passes between the first message and the next message. So the SSL protocol also defines a “heartbeat” or keep-alive request that will maintain the connection and keep it from timing out.
Content of a Heartbeat Request
The heartbeat request is relatively simple. The client sends a “heartbeat” to the server with two items: a “secret message” and the length of that secret message. The server is supposed to respond with the complete secret message. The length argument is in there in case the message gets broken up into multiple smaller messages along the way since that can happen. So if your client sent the request “Message: Transformers, Length: 12”, the server is supposed to respond with “Message: Transformers”. It shouldn’t respond with anything else like “Robots in disguise” or “Optimus Prime” or “HailMegatron” because that’s not what the client is expecting to get back.
The “Heartbleed” Bug
On December 31, 2011 (yes, more than 2 years ago) a change was made to the code in the OpenSSL implementation of the SSL protocol. OpenSSL is an open-source SSL implementation licensed under terms similar to the BSD License in that the source is freely available and changes can be made without restriction or inclusion back into the original source. OpenSSL is used heavily in most open-source web servers, most notably Apache.
The code changed the way the server validates the reported message length compared to the actual message length. Instead of simply parroting back the message it received, the server returns back the contents of memory starting with the message for the reported length of the message in what’s known as an overflow bug. This is a problem because the contents of memory can be anything from passwords to the server’s core certificate as long as it’s been loaded by the current process. That’s very, very bad.
The length field maxes out at 64,000 so an attacker could read 64KB of memory at a time. There’s also no limit to how often a heartbeat can be sent, so multiple heartbeats could be sent in rapid succession and the server will respond to all of them. Thus, a sophisticated attacker could get a near complete mapping of the server’s memory and everything in it. So it’s not hyperbole to say that systems that use the offending code are incredibly vulnerable and a large amount of (not just user) data could be compromised as a result.
Below is an oversimplification from the XKCD comic of how heartbleed works that provides a healthy amount of FUD. We’ll go into detail on why this is an oversimplification below.
What Systems are Affected?
So now that you understand how bad Heartbleed is, what websites have been affected? The good news is the answer isn’t “All of them”. In fact, the answer might not even be “most of them”. It will all come down to which sites you use every day. As I mentioned previously, OpenSSL is the only affected plugin so only systems that use OpenSSL are affected.
Unfortunately, the list of affected companies includes such names as Facebook, Yahoo, Instagram, Twitter, Tumblr, and Google. All of them used the affected code. So if you use Facebook, Yahoo Mail, Gmail, etc. then you could be affected.
One thing I want to make clear is no sites running Microsoft’s web server (IIS) are affected, nor are the majority of banks (especially the largest banks e.g. Citi, Bank of America, etc.), or Amazon.com.
You can find an up-to-date listing of affected sites here: Which Sites Have Patched the Heartbleed Bug
How Bad Is It?
It’s bad. Make no mistake that until systems are patched, it’s going to be incredibly easy for attackers to go after data on those systems.
There are plenty of nightmare scenarios where an attacker gets their hands on the master key for a server (or the master key used to secure other keys). They’d then be able to listen in and decrypt any traffic coming from that server provided they can insert themselves into the route between the client and a server to capture the traffic.
There are also scenarios where passwords are stolen and hackers run amok with credit card numbers.
How bad is it really?
Leaving all hyperbole aside, it’s unlikely that this attack is going to amount to much other than a bunch of page views and scared users. I’m not saying that there is no threat, there absolutely is. But some of the advice of “change all of your passwords now and don’t use the web until the sites you use are patched” is more sensational than practical for the average user, especially since there are limited reports of affected sites actually being attacked. And of those sites, no one knows what data the attackers actually got or if it was useful.
Let’s step back and look at what is actually vulnerable in this attack: anything within the process’s RAM memory space. This could be things like:
- The server’s private master key that it uses to send and receive all data
- User passwords and other request data stored in RAM
However, a lot of stuff isn’t vulnerable to this bug. Every modern operating system uses process segmentation to keep other process’s hands out of the proverbial cookie jar that is RAM. Even though OpenSSL will read the data 64,000 characters past the start of the secret message in memory, it can’t read past the end of the current process’s memory space. This is a limitation being enforced by the operating system and the vulnerability doesn’t affect that. So anything running in a separate process is safe.
Additionally, the process doesn’t read from the hard drive to return the heartbeat, so none of that data is at risk either. An attacker can’t use this vulnerability to steal data stored in a database or movies stored on Netflix.
More importantly, the data an attacker does get back is not going to look as nice and neat as the XKCD example. Realistically, it’ll just look like a huge jumble of random data. Without any knowledge of how the process actually works, which an attacker wouldn’t have, there’d be no guaranteed way to identify a server’s master key, say, from a Base64 encoded request. It’s not like data in memory looks like “Master Key: 1234567890, Password: Password”. It’s true that many requests to map the memory space will help identify patterns in the memory that would aid in identifying specific variable and consistent aspects (passwords being the former and keys being the latter).
This is why it’s something that needs to be fixed and it’s a good idea to change your password for sites that are affected. However, the web as a whole isn’t broken and there’s not going to be any drastic shift in user confidence.