Yesterday the security engineers at Codenomicon disclosed a high severity security vulnerability in one of the most used SSL libraries in the world – OpenSSL.

According to advisory published on the vulnerability exists on 1.0.1, 1.02-beta, 1.01f and 1.02-beta1 versions and seems to impact millions of servers, please upgrade to the latest version of openSSL 1.0.1g.

What’s Heartbleed bug?

OpenSSL implements Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols which designed to secure traffic from unauthorized attackers. An extension called Heartbeat is being used to keep connection alive between client and server that use TLS connections, the security vulnerability found in that extension and that’s the reason the researches named the bug as “Heartbleed”.

How the bug behaves

We downloaded the latest version with the security fix (1.0.1g) and one version before (1.0.2-beta1), searched for the function who handles the process of heartbeat extension, and performed a diff between the two versions.



* Comparison between vulnerable OpenSSL 1.0.2-beta1 against the latest fixed version 1.0.1g (Click on the picture above to see it correctly)

From the above comparison we can learn a lot about the heartbleed security bug, on the left you can see the old vulnerable version:

/* Read type and payload length first */

hbtype = *p++;
n2s(p, payload);
pl = p;

The first line, extracts the type of the heartbeat message received, second line extracts from received message the length of the received message, the code doesn’t check if the length given by the remote client is correct.

/* Allocate memory for the response, size is 1 bytes
* message type, plus 2 bytes payload length, plus
* payload, plus padding
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

/* Enter response type, length and copy payload */
s2n(payload, bp);
memcpy(bp, pl, payload);
bp += payload;
/* Random padding */
RAND_pseudo_bytes(bp, padding);

r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);

As we can see later on that function, it allocates memory based on the given unchecked length from the remote client, generates a response and send it back to the remote client. That means we can actually give length up to 65K without providing a message in that size, then the function will build response message and try to copy payload in the size provided by the client, that will cause copy of 65K of memory that may contain important information about the server such as encryption keys, user names password, etc.


We highly recommend for all sys admins to check and verify they have the latest version of openSSL (1.01g), in the near future it seems we’ll have a lot of interesting stories about it, hold tight.