The biggest recent fuss in the field of computer science gains notoriety day by day. Online references to the bug have multiplied over time. Anyone having basic understanding of the field of computer science and programming would know that bugs in software are very common and they come and go daily. So, what is Heartbleed and what makes it unique and so notorious?
To skip all the background and technical details skip to the section Simplified explanation of the Heartbleed bug.
What is Heartbleed?
It
is a serious vulnerability (a software bug) in the popular cryptographic
software library OpenSSL. This bug allows a malicious user (commonly called hacker) to steal protected information
over a communication channel secured by the SSL/TLS encryption, which has
OpenSSL lying at its implementation.
Specifically,
this bug lies in the Heartbeat
extension of OpenSSL.
What is SSL/TLS?
Transport Layer Security
(TLS) and
its predecessor, Secure Sockets Layer
(SSL) are cryptographic protocols designed to provide security for
communication over Internet. SSL/TLS protocols
essentially are a set of specifications that define the mechanism for a secure
communication.
Where do we see SSL/TLS?
Secure
communication over Internet uses the SSL/TLS protocols. Most of the
confidential information over Internet is communicated using the HTTPS
application protocol that utilizes SSL/TLS protocols. Nearly all websites,
web servers, chat servers, network appliances where confidential and private
information can be exposed use SSL/TLS; examples include Bank websites, payment
gateways, email providers, social networking websites and numerous other
websites.
What is OpenSSL?
OpenSSL
is a cryptographic software library that provides an implementation of the SSL
and TLS protocols too. It is considered the de facto library used for incorporating SSL/TLS
security on a website. So, if a website uses SSL/TLS security, there are very
high chances that it uses OpenSSL implementation.
If there are vulnerabilities
associated with using SSL/TLS security, why use it at all?
The
vulnerabilities are not associated with the SSL/TLS protocols; the
vulnerabilities exist in specific implementations. It is like saying, if items
from my house can be stolen; why not leave them out in the open? :)
Okay, if the
vulnerabilities exist in specific implementations; are there other
implementations of the SSL/TLS protocols?
Yes, there are a host of other implementations of
the SSL/TLS protocols. See A Comparison of TLS Implementations
for a comparison of such implementations. That said, OpenSSL is a very popular
cryptographic library that has proven to be highly reliable and efficient over
time. A bug does not make it a bad choice (since the bug has already been
fixed); it is natural for other implementations to have their own set of
problems too.
What is the
heartbeat extension?
OpenSSL introduced an extension called Heartbeat
around December 2011, with its 1.0.1 build release. The extension’s task was to help avoid
reestablishing sessions so that the SSL sessions could be kept alive for longer
durations.
How does the Heartbeat extension work?
Without going into the intricate details of the
headers formats, we can have a simple understanding of the Heartbeat
extension.
When a session is established, the server and the client
(or the two peers) establish session keys. However, after regular intervals,
the client and the server need to verify each other’s identities because of a
variety of security reasons (like session hijacking).
One approach is to establish another session. Since,
establishing a session requires multiple steps, this is considered inefficient.
Another approach (the one that the heartbeat extension follows) is to setup two code words in the beginning, one for the client and one for the
server. Now, after some time (called a Heartbeat),
the server asks the client back for its code word (of course, encrypted by the
session key). If the client replies with the correct answer, server knows that
the client is authentic. If the client cannot reply, or gives an incorrect reply,
the server asks for reestablishment of session (asks again for the password).
Similarly, the client verifies the server’s identity
by requesting the client’s code word. If server is unable to reply correctly,
the client asks for re-verification of its certificate.
Okay, then,
what exactly is the Heartbleed bug?
As we already saw, an exchange of secret code words is
performed during a persisting session to verify the identity of two
communicating peers.
However, due to the Heartbleed bug, the client not
only has access to the session key but also an arbitrary chunk of memory on the
server side (similarly server has access to client’s memory).
The client, while verifying session, send a request
to the server to return back the client's secret code word that was established
earlier. In the request, client also sends the size of the data it expects the
server to return. Even if the secret code was a few bytes long, the client can
always request a bigger chunk of memory (an upper limit of 64 KB in one
heartbeat). The server fulfills the request giving that amount of memory data
back to the client (starting from the key’s location in the memory).
So, if a
client is a malicious client, it can keep sending heartbeat requests to the
server potentially accessing up to 64 KB of arbitrary memory every time. That
portion of memory can contain highly confidential data, including the server’s
private key (access to which gives unrestricted access to the server), other
user’s data etc.
Can you skip
the technical details and explain in simple terms?
Okay, let’s skip all the encryption stuff. Let us
imagine a scenario where you visit a bank. The receptionist asks you for your
secret key (the password) to enter the bank. You also ask the receptionist for
her identification. Once, you are satisfied with her credentials, you tell her
the password. She verifies the password and lets you access the inside of the
bank.
However, you two also setup code words for further
communication. You tell the receptionist your code word and the receptionist
tells you her code word. Receptionist passes these code words to all the bank’s
employees, so that anyone who knows them is an employee and anyone who doesn’t
is not.
Now, you are sitting in the waiting room waiting to
be assisted. Now, an employee comes to assist you. However, instead of asking
your password again (having to verify it from the system), he simply asks for
the bank’s code word. You ask him your code word first. He tells you your code
word and establishes that he is an authentic employee of the bank.
However, the employee is infected by the deadly
heartbleed bug. So, while asking your code word, you tell him how many words
you are expecting. He tells you the
correct code word but also tells other visitors' code words, and the bank’s
code words for other visitors too, depending on the number of words you said
you were expecting.
This knowledge gives you unnecessary access to
private information related to other visitors. You can even impersonate as one
of them.
To throw in a little technicality, the situation
with OpenSSL is not as bad as the bank’s, because code words are not stored as
plain texts. They are encrypted using session keys. So, just to decipher the
code word, or any part of memory that was leaked, a hacker would first have to
hijack a session (basically know who to attack).
Bugs in
software come and go, what makes Heartbleed so unique?
The severity and ease of exploitation of the bug
makes it so notorious.
The bug is
very easy to exploit, does it leave the Internet insecure to all hackers?
No, it doesn’t.
The reason is, a hacker has access to arbitrary chunk of memory but he
doesn’t know what part of memory (or what information) he is getting. Essentially, all he might be getting could be garbage or could be the bank
account’s password of a user. It takes a mediocre hacker to exploit the bug but
someone very good to get important information out of the leaked data.
How do I know
that I was attacked?
You don’t. The exploitation of the bug leaves no
traces, so there is no way to know if someone has already accessed your confidential information. However, if something bad hasn’t happened yet, there
are pretty good chances that you weren't attacked.
How do I
ensure that Heartbleed no longer affects me?
The OpenSSL developer community promptly fixed the
bug, and fixes have been pushed by most operating systems. All you have to do
is update your OpenSSL with the latest set of updates. After that, ask your
users to change their passwords to protect from any future information theft
due to an earlier password leak.
For background information on the Heartbleed bug,
visit the Wikipedia article on Heartbleed.
