ASKME.Bar is an online community where anyone can get their desire solution for any technical problems by certified professionals. If anyone can join our expert panel then sign up our online community at

Author Topic: Heartbleed – Another coding error that is Responsible for security crisis  (Read 180 times)


  • Guest
OpenSSL is an open source code library where you can trace the mistake in a single line of code that caused the Heartbleed vulnerability. This article will help you to understand how Heartbleed works, how it was traded upon, and how can you deal with it if you have an unpatched server.
It was the month of April in2014 when we heard about Heartbleed vulnerability. It is a vulnerability that was present on thousands of web servers including major sites and allowing attackers unprecedented access to confidential and sensitive information.

This vulnerability occurred because of flaw in OpenSSL. OpenSSL is an open source code library that implemented the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. Using this vulnerability, a malicious user can easily trick in to a web server for sending sensitive information, including IDs and passwords.
For modern web encryption, the TLS/SSL standards are crucial when the flaw was in the OpenSSL implementation rather than the standards themselves. At the time when the bug precipitated in a security crisis and was made public, OpenSSL was so widely used that it affected 17% of all SSL servers.

How Heartbleed works

To get the understanding how the Heartbleed vulnerability (CVE-2014-0160) works, you need to get some knowledge about how computers store information in memory and how the TLS/SSL protocols operate.

A heartbeat is one important part of the TLS/SSL protocols. Essentially, this is how the two computing devices communicate with each other and they are still connected even if the user is not uploading or downloading anything at that point of time. Occasionally, while communicating with each other, one computer will send an encrypted piece of data to the other and this is called a heartbeat request. The other computer will reply back with the exact same encrypted piece of data if the connection is still in place. The heartbeat request contains information about its own length.

The reason why Heartbleed vulnerability arose is missing a crucial safeguard while implementation of the heartbeat functionality in OpenSSL. The computer that got the heartbeat request never checked the request in order to verify that how long it was or was it actually as long as it claimed to be. If a request said it was 40 KB long but actually, it is only 20 KB, the receiving system would set 40 KB of memory buffer aside, then store the 20 KB that it would have actually received, then it will send back that 20 KB plus whatever has to happen with the next 20 KB of memory. There us that extra 20 KB of data is information that the attacker has now extracted from the web server. As far as the device operation is concerned, this is the crucial part and it persists in memory buffers until there is something else that comes along to overwrite it even though the system is done with information.

Attackers who don’t know anything in advance that what might be lurking in that 20 KB can just grabbed off the server. However, there are multiple possibilities and that may be gibberish or useless cruft. There are SSL private keys that attackers you can get to decrypt secure communication to that server. You can also get back usernames and passwords that are submitted to applications and services running on the server and you can use this information to log in and gain access.
In computer science, Munroe's specialty web comic xkcd is known for making difficult scientific concepts accessible and this comic does a great job for summarizing the function of the Heartbleed vulnerability in a concise way.

Heartbleed bug code

The coding that caused Heartbleed is caused by the coding mistake that can be traced to a single line of code:

memcpy(bp, pl, payload);
memcpy() is the command to copy data.
bp is the place where the copied data will be out and pl is the place where it's being copied from.
payload is the copied data length.

The problem persists because there's never any attempt to verify that the amount of data in pl is equal to the given payload value. One thing is very ironic about OpenSSL. It is open source software and anyone could see the code, and presumably many did, but when it comes to the fairly elementary coding error, nobody noticed.

Heartbleed exploits

Before being widely publicized, it was not clear that any real-world exploitation of the Heartbeat vulnerability has taken place. In early 2013, many security companies were probing for the vulnerability and some detected attempts. When the vulnerability was made public after April of 2014, companies struggled to update their systems, they tried it and even then hackers managed to exploit it in several cases.

How heartbleed vulnerability can be fixed

As soon as the vulnerability was announced, patches were rolled out for OpenSSL on the same instant. By that point, most formerly vulnerable servers were updated, but still there would be some server that could be important for have been chugging along for years because there is no proper upgrade. There are many websites that offers web-based test and let you input a URL to find if a server has been properly patched.

Upgrading OpenSSL to the latest version is one of the ways to fix the Heartbleed vulnerability. There are links to all the latest code on the OpenSSL website that you can find and use. If you want to see the code that implements the fix, you can see it as it is OpenSSL is open source:

* Read type and payload length first */
if (1 + 2 + 16 > s->s3->relent)
return 0;
/* silently discard */
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 cause of creating problems is the first part of this code that makes sure that the heartbeat request isn't 0 KB. The second part verifies that the request is actually of same length as it says it is.

If you find that a server under your control is left vulnerable for some time, then you can do more than just updating the OpenSSL code. In that case, you can change the SSL certificates used by the servers because there may be the possibility that they may have been compromised without leaving a trace. Traditional, but very important, users have accounts on the system should change their passwords.

Technical Questions & Answers


Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
Legal Disclaimer: All registered trademarks belong to their respective owners. The use or mention of any trade name, product name, or trademark in this website is in no way intended to suggest that the trademark owner is at all affiliated with or endorses this site.

Terms & Condition | Privacy Policy