Heartbleed – What went wrong ?

Background :

These days almost each and every website asks user for registration and provides them with an username and password for there future interaction with the website.Today HTTPS protocol is the defacto standard for sending the sensitive data to the server and behind the scenes Secure Sockets Layer (SSL) and Transport Layer Security(TLS) protocols which make sure that every transaction between the client and server is secure.

Today most of the websites uses the OpenSSL as an implementation for SSL and TLS protocols ,though there are other implementations like PolarSSL,SChannel(developed by Microsoft) etc are available but OpenSSL is the most robust and widely accepted as majority of sites like Yahoo,Flickr,500px etc uses it.

OpenSSL makes sure in setting up the identity of the client and server to who they claim who they are.Once a connection is established between them , both client and server continuously do encrypted handshake with each other to know that they are alive.More specifically in OpenSSL they call it as Heartbeat ( from where Heartbleed is originated) where client and server sends some data to each other to ensure that both of them are enjoying on their sides.

What is Heartbleed ?
Heartbleed is the security hole that was found in the OpenSSL implementation for sending this heartbeat data to the client.As a part of heartbeat when client sends data (max 64KB) to the server it sends three parameters to the server -

 

1. Location on the server where this data will reside
2. Payload that needs to be copied.
3. Size of the payload that needs to be copied.

Let’s have a look at the actual function that is actually responsible for the copying of this payload and root cause for the Heartbleed.

memcpy(bp, pl, payload);

1	memcpy(bp, pl, payload);

It’s a C function that takes 3 parameters as explained above bp is the location on your server where this payload is going to reside,pl is actual payload send by the client,payload is the size of the payload that can goes up to maximum 64KB.When server receives a heartbeat from the client it tries to find a free location on the server to copy this data but practically there is no such empty space exists on the server,so server reads the bp that is location where pl will reside but in actual this location is not empty and contains data that has been used in other sessions and flagged for deletion as it’s a garbage data.

Now memcpy thinks it is safe to use this location as it is already being marked for deletion and creates a chunk equivalent of payload size at this location and copies all the data present in pl to this chunk. So, till now all good garbage data has been replaced with the data send by the client and the same data has been send by server back to the client as a part of heartbeat.

Now the interesting part when client starts lying, that means it stops sending any data in pl and in payload claims that it is sending 64KB of data , so here is flaw in the bugged version of OpenSSL where no validation was present to check whether the size of data in pl and value in payload are same.

Server is still trusting the client and expecting the client will always sends the same size data in pl what it promises in payload , under this assumption server will again create a 64KB (payload value) chunk in the location pointed by bp and copy all of the pl data there i.e nothing so this time garbage data is not replaced and it is still there.Now this garbage data can contain complete useless data or some sensitive information like passwords , credit card details etc and will send back as a server heartbeat to the client.Once this heartbeat is received on the client side , practically anything can be done with this data (it’s terrible to imagine).

Enough technical let’s try to understand it with a simple example (purely hypothetical).

Assume there is a stationary shop whose main business is of doing photo copies.Owner (our server) of this shop is partially illiterate and doesn’t know basic counting for him all the numbers are same (1=2=3=4…) and he also never checks the document whether in reality it exits or not.

Now a customer approached him (our client) and asked him to do a photo copy of 100 documents that he brought with him, once copying is done owner started searching for an empty envelope to put these copied documents but like always he didn’t find any ,so he picked one of the envelopes already filled with some other documents(Assumption:an envelope can contain max 100 documents).

As this owner doesn’t know the basic counting so he was not sure of many documents are present in this envelope,so he starts removing documents from envelope one by one and as soon as he removes a document from the bottom of the pile he places a new document at the top of the pile.He continued this process until all the new copied documents are finished.In our ideal case when client is not lying everything goes fine and whole of the older documents are replaced by copied ones.

Our customer has observed all these things carefully and find out the problem with the our owner.Next day he went again to this shop and this time he didn’t take any document with him and asked the owner to do 100 copies of this document(in actual no document).As said earlier owner doesn’t care whether document exists or not , he made 100 copies of it (in actual 0 copies) and started the same process again.He picked one of the filled envelopes and start keeping these copies (that don’t exist). This time without keeping any copied document into the envelope because there was no copy , he handed over the envelope to the customer which contains the documents of some other customer X. Now our smart customer has documents of some other customer X and he can do whatever he wants with these documents.

PS:This example may not exactly replicate the actual issue but to some extent there is a correlation between actual loophole and above example.

Xkcd also presented a nice comic explaining the Heartbleed.