April 25, 2018
Back in April 2014, one of the biggest vulnerabilities in recent history
HeartBleed. The popular open
source cryptographic software library
OpenSSL, had a critical
 in the implementation of a extension on the
Transport Layer Security
The wide use of
OpenSSL on several services such as web,
email, instant messaging
(IM), even virtual private networks
(VPNs), managed to affect
SSL servers, mostly half a million of trusted websites.
In this article we will see how it works, in a simple yet technical language.
Figure 1. xkcd Heartbleed
TLS Protocol brief explanation
TLS protocol aims to provide secure communications between
servers and web browsers. Whenever you see in your web browser a
green lock next to the url, it means you
are visiting a secure website, indicating that your communication with
the website is encrypted, specially designed
to prevent eavesdropping
Figure 2. Secure URL, Green lock sample
TLS accomplishes that by encoding your data in a way that only
the recipient knows how to decode it. If a third party is listening
to the conversation, it will only see seemingly a random string of
characters, not the actual message or content of your data.
From Beat to Bleed
HearBeat extension was a change proposed by
Dr. Seggelman in 2012, and the bug was
fully disclosed on April 7, 2014, by independent researchers at
Google Security. According to the
RFC-6520, it’s a new extension
TLS/DTLS, which provides a way to perform a
Basically, a device sends an echo with a message to be replied
back with the same information, just to make sure if the other
device is still alive. If any of them goes down during the
transaction, the other will know it by using this
So, for example, you are reading this article, but you haven’t done anything in a while, your web browser sends a message to the server saying "Hello - Repeat it back to me", the server receive it and send it back to your browser.
The bleeding flaw
Researchers found that if a request made had a bigger length than what was sent on the message, extra information could be leaked at the response sent back.
For example, the web browser sends the following message:
"Hello - Repeat it back to me (28 kB)"
But the length of the request is modified to 40 kB, then it
"Hello - Repeat it back to me (40 kB)"
Then the message is sent and the recipient device gets a message with a length of 40 kB.
But the message was suposed to be 28 kB long, what about the remaining 12 kB? The recipient machine allocates in memory buffer those extra 12 kB of data and send back 28 kB of the actual message plus extra 12 kB of whatever is stored in RAM. Practically, you get more than the beat, instead, you can actually make it bleed, literally.
Figure 3. Bad luck
Why? You may ask. The message can be up to 64 kB, not a lot of information leaked though, just 65536 characters taken from no other place than RAM, but it’s not like if an attacker could control which portion of the RAM wants, it just get whatever the machine grabs in the subsequent block of memory.
But that doesn’t seem to be harmful, probably no more than random data
being sent, what’s the chance it can get something of real value? What
if I told you an attacker doesn’t have any limit to send
HeartBeats? It can stay all day long sending requests
analyzing each 64 kB sent back and forth, and suddenly, the flaw
could yield some, if not all of the following:
Usernames and passwords that are submitted to applications and services running on the server.
The worst of this vulnerability, is that there’s no way to trace
it, records for this kind of activity aren’t logged by the
daemon. Plus it’s not a client-server vulnerability, as malicious
servers were able to exploit it on clients using the
vulnerable version of
OpenSSL, called a Reversed HeartBleed's.
Figure 4. xkcd Heartbleed explanation
What caused the bug?
This is a portion of the code of the
v1.0.1f (the vulnerable version). This fragment contains the bug and
I’m gonna break it in the essentials details.
Fragment of the t1_lib.c from
The line responsible for the vulnerability is this one:
3997 memcpy(bp, pl, payload);
Looking at the documentation of
memcpy, we see the following:
Figure 5. memcpy function
The terms in parentheses behave like this: bp is the destination of
the memory copied from pl, pl is the source of that memory and
payload is the length of it, basically, the last one says how large
is the data.
If payload states that pl is of 64 kB, when it really is of 0 kB we got a huge problem, because bp will be created with the same size as pl, filled of garbage data, but then none of that data at bp gets overwritten, because pl is empty or isn’t large enough to fill it.
The flaw on the code is that the length of the data wasn’t being validated, there were a missing bounds check before memcpy was performed. We’ll see that in the following lines of code:
/* Read type and payload length first */ 3972 /* Read type and payload length first */ 3973 hbtype = *p++; 3974 n2s(p, payload); 3975 pl = p;
The previous three lines of code just write the length of p, the '`HeartBeat` request', into the variable payload, the expected length of the payload. But notice there’s nothing checking if the expected length of the message corresponds to the actual length of the '`HeartBeat` request'.
The next line is responsible to set the length of the response back, the payload variable holds the expected length of the payload, thus that length will be written into the bp variable.
3996 s2n(payload, bp);
Now, the line containing the vulnerability explained before, takes a little more sense, pl could have a length of 5 kB, but payload gets a value of 64 kB, as it is not checked, bp variable will allocate in memory those 64 kB and send it just back, .
3997 memcpy(bp, pl, payload);
The vulnerability is only present in versions
1.0.2-beta1 releases. A few days after the incident
a patch was released, the
got rid of the flaw.
The patch is essentially a bounds check, to validate the actual length of the payload.
hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */ pl = p;
The fully code patched can be seen here in this
This kind of vulnerability is named
. For example, in the
Heartbleed case, the
program tries to read data from memory, but due to no bounds check, it
tries to read adjacent memory, creating a special case of memory safety
That was all?
Yes! That single line you saw there was the demonic 'call of Cthulhu'.
Nah, not really like that, but it tempted to wreak havoc, several
the Canada Revenue Agency
almost 78 devices from
operating systems shipped with it, like
Ubuntu 12.04.4 LTS, and a big
etcetera had to shut online their services, warn or log out every user
and inform them to update their password, there were even possible cases
of the bug
Yet, despite 4 years have passed, there’s a high chance that a lot of
HeartBleed, since there are plenty reports from 2017 showing
that at least 200,000 services are still
offer Software Composition Analysis
to find vulnerable software components in our clients' systems.
Our clients can then manage these vulnerabilities
in our Attack Resistance Management platform.
IBM (2014). A technical view of the OpenSSL HeartBleed vulnerability.
Recommended blog posts
You might be interested in the following related posts.
Injecting JS into one site is harmful, into all, lethal
Differences between these security testing approaches
Our CLI is an approved AST tool to secure cloud apps
A simple approach to try out in cybersecurity training
Open the door to security as a quality requirement
Use of automated tools only? Don't stick to your guns!
So it's the app itself that delivers the cookie to me?
And round it off with our Secure Code Review