How the Heartbleed vulnerability works

I’ve been reading about the Heartbleed bug, trying to understand how it does what it does, how a hacker could use the vulnerability to gain access to your data.

If you have not heard of Heartbleed, read this, which was posted last night.

Is Heartbleed bad?

In case you’ve been out of the loop, Heartbleed (CVE-2014-0160) is a vulnerability in OpenSSL that allows any remote user to dump some of the contents of the server’s memory. And yes, that’s really bad. The major concern is that a skilled user could craft an exploit that could dump the RSA private key that the server is using to communicate with its clients. The level of knowledge / skill required to craft this attack isn’t particularly high, but likely out of reach for the average script kiddie user.

I’m not well versed in this sort of thing, but here’s my take on how this works.

First, a script is run against a vulnerable server. The vulnerability allows a raw chunk of RAM to be retrieved from the server. The exploit is repeated until a chunk of RAM is retrieved containing a GET request. For the exploit to have value, the retrieved RAM has to also contain an authentication cookie. Different servers, different cookies.

Once a cookie is retrieved, you build a new request using that cookie and, since the cookie matches an existing session, your request is considered part of the existing session and you now have control over that session. Once you control a session, you are, in effect, logged in to the server.

If you see a hole in my explanation, please clarify in the comments for the benefit of other readers. This seems a pretty big hole to have skated through all this time.

  • Graham Hill

    That is one potential attack; there are others, depending on what you are able to get back in the retrieved RAM. As well as hijacking sessions, you might get hold of confidential documents from other sessions, retrieve usernames and passwords from other sessions, or even retrieve the private key of the server’s SSL certificate.

  • Robert Davey

    It’s worse than that, if they hacker manages to get the private keys back from the server they can now pretend to be that server with a valid certificate. It also means that when you have an encrypted session to one of these servers anyone who’s compromised that key will be able to decrypt data they capture. As far as I can tell just patching the server won’t be enough to guarantee this is cleaned up, the server operator will also need to get a new certificate issued and revoke the old one to ensure future connections are secure again.

    • Jake Lazaroff

      Yup. This is the worst part; an attacker can impersonate ANY server with this vulnerability.

  • Václav Slavík


  • Robert Davey

    Ars Technica responded to the vulnerability quickly with server patches and certificate revocations etc, but still had people with stolen accounts in the few hours they were vulnerable!

  • Send this to the comment bozos at Gizmodo, who do not believe large potentially dangerous exploits can make it out into to the wild.

    Whenever Apple is concerned that is…