In this post we are going to explain:

• how the Heartbeat bug works;
• how you can check websites to see if they have the bug;
• how it affects Apache mod_ssl and Nginx ngx_http_ssl_module, both of which use OpenSSL; and
• what you need to do.

The Heartbleed Bug (security advisory CVE-2014-0160) affects OpenSSL versions 1.0.1 to 1.0.1f.

Heartbleed Bug Explained

We take this explanation from http://www.theregister.co.uk/2014/04/09/heartbleed_explained/ and summarize it ourselves.

The Heartbeat is a way to maintain SSL session persistence. The bug is contained in the SSL3 heartbeat message.

The graphic below shows the c-language code for the Heartbeat message in the OpenSSL source code.  In this data structure, the length of the message is given as payload_length.

This is the SSL record structure, from the SSL standard.  It shows the length as well.

In the graphic below, we see that the heartbeat length sent to the user (it could be the web server or the browser) from the SSL3 record is 4 bytes.  But the OpenSSL code reads the length as payload length from the OpenSSL structure and not the SSL3 structure.  So a program could exploit this to tell the program to read beyond the legitimate length of the SSL3 heartbeat.

In the sample below the area shaded in red is data beyond the length of the TLS1_HB_REQUEST.  That, of course, gives the program access to memory outside the OpenSSL heartbeat message. That is where a hacker would find data that it should not be able to read, like a web server private key.

In this widely published photo of the exploit being used against Yahoo email, you can see that in this example, that out-of-bounds memory clearly shows the user’s password (it has been blacked out).

What Does this Mean?

This bug means someone can use tools (see below for example) to probe a web server and then, with perseverance and some luck, be able to find the web server’s private key.  We say perseverance, because someone would have to try over and over again to dump the maximum buffer of 65534 bytes, look at the memory, and then look for something like this (this is not an X.509 certificate but a PGP one: we just show it to illustrate the point).

-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: BCPG C# v1.6.1.0
lQOsBFIrW9ABCACMkruK3w87klVbttcp5lTsqOUBDWLG+mc1at4r03qkfDzgrtUL…

By doing this the hacker could obtain the:

1. Web server private key;
2. User session keys; and
3. User data like passwords.

If a hacker obtained the private key, they could set up their own website using the private key of a legitimate site and then generate SSL certificates that would not be challenged by the browser.  This is because the certificate authority would already be trusted, although the CN of the certificate would not match the domain of the site.  In other words, they could pretend to be a legitimate website and then send users there using phishing attacks.

If someone obtained the session keys, they could use these to replay one user session and decrypt that.  This would be difficult to do in real time.  But they could use it to decrypt previous web traffic to that website if they could match up the session key with that one user’s session.

If someone obtained passwords it is obvious what this means.

Who does it affect?

You can check if a website has a version of OpenSSL with this bug using this website http://filippo.io/Heartbleed/ or you can download a Python program from here https://gist.github.com/takeshixx/10107280 to probe the site and see if it returns memory outside the Heartbeat buffer.

Using Python 2.6, here are the results we got when we probed the Russian Bank RosBank:

It says the website has “likely” been patched, meaning the program cannot say for sure.  If the site had the problem, it would show the memory it was able to read, so you would know the bug is definitely there.

To fix your own website you will have to either (a) download the latest OpenSSL distribution or (b) recompile Apache or Nginx.  We discuss this below.

Apache Mod_ssl

The Apache module mod_ssl uses OpenSSL to for SSL.

The current version of the Apache windows binary (2.2.22) that includes mod_ssl is from 30 January 2014.

As you can see it uses OpenSSL 0.9 which is from 10 May 2012.  That does not have the bug, since the bug affects OpenSSL versions 1.0.1 to 1.0.1f:

3782486 May 10 16:41:36 2012 openssl-0.9.8x.tar.gz

What about if you built Apache yourself?

If you are using the Apache module mod_so, which allows modules to be dynamically linked (loaded at run time).  This is true for Windows and Linux.  That means you can download the OpenSSL library to patch your system and you don’t have to do anything else. If not, you will have to download the mod_ssl source code, OpenSSL source code, and then recompile your Apache web server.

Nginx ngx_http_ssl_module

If you look at the source code ngx_http_ssl_module.c you can see it clearly says the OpenSSL library is dynamically linked.  That means it is loaded at run time and you would not have to recompile Nginx on a running system. Just download the latest version of OpenSSL.

How do I know if my OS is affected?

The short answer is it is affected if (a) it is less than 2 years old [i.e. prior to OpenSSL 1.0] and (b) you have not patched it.

For example, Ubuntu 12.04.4 says it uses open SSL 1.0.1.  So it has the version of OpenSSL with the bug.  You can check that like this:

What do you need to do?

• Generate a new private key and go get new server certificates; and
• Change all your passwords.

Your users should change all their passwords too, but you do not need to tell them that.  They probably have already read about it in the news.

Other questions

Support for OpenSSL is built into modules for Java and Python, and other programs and devices besides web servers.  Presumably these do not use the Heartbeat module needed to maintain persistence with a user. But that would warrant further investigation. Security researchers have not talked much about whether programs beside SSL, like applications, would have this weakness as well.

We patched our OpenSSL on April 7: the same day the problem was revealed, so Anturis’ users are safe. But as an additional precaution to protect your data, we highly recommend that all Anturis’ users change their account passwords.