How do I recover from the Heartbleed bug in OpenSSL?

This vulnerability has a high potential impact because if your system has been attacked, it will remain vulnerable even after patching, and attacks may not have left any traces in logs. Chances that if you patched quickly and you aren't a high-profile target, nobody will have gotten around to attacking you, but it's hard to be sure.

Am I vulnerable?

The buggy version of OpenSSL

The buggy software is the OpenSSL library 1.0.1 up to 1.0.1f, and OpenSSL 1.0.2 up to beta1. Older versions (0.9.x, 1.0.0) and versions where the bug has been fixed (1.0.1g onwards, 1.0.2 beta 2 onwards) are not affected. It's an implementation bug, not a flaw in the protocol, so only programs that use the OpenSSL library are affected.

You can use the command line tool openssl version -a to display the OpenSSL version number. Note that some distributions port the bug fix to earlier releases; if your package's change log mentions the Heartbleed bug fix, that's fine, even if you see a version like 1.0.1f. If openssl version -a mentions a build date (not the date on the first line) of 2014-04-07 around evening UTC or later, you should be fine. Note that the OpenSSL package may have 1.0.0 in its name even though the version is 1.0.1 (1.0.0 refers to the binary compatibility).

Affected applications

Exploitation is performed through an application which uses the OpenSSL library to implement SSL connections. Many applications use OpenSSL for other cryptographic services, and that's fine: the bug is in the implementation of a particular feature of the SSL protocol, the “heartbeat”.

You may want to check which programs are linked against the library on your system. On systems that use dpkg and apt (Debian, Ubuntu, Mint, …), the following command lists installed packages other than libraries that use libssl1.0.0 (the affected package):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

If you run some server software that's on this list and listens to SSL connections, you're probably affected. This concerns web servers, email servers, VPN servers, etc. You'll know that you've enabled SSL because you had to generate a certificate, either by submitting a certificate signing request to a certification authority or by making your own self-signed certificate. (It's possible that some installation procedure has generated a self-signed certificate without you noticing, but that's generally done only for internal servers, not for servers exposed to the Internet.) If you ran a vulnerable server exposed to the Internet, consider it compromised unless your logs show no connection since the announcement on 2014-04-07. (This assumes that the vulnerability wasn't exploited before its announcement.) If your server was only exposed internally, whether you need to change the keys will depend on what other security measures are in place.

Client software is affected only if you used it to connect to a malicious server. So if you connected to your email provider using IMAPS, you don't need to worry (unless the provider was attacked — but if that's the case they should let you know), but if you browsed random websites with a vulnerable browser you may need to worry. So far it seems that the vulnerability wasn't being exploited before it was discovered, so you only need to worry if you connected to malicious servers since 2014-04-08.

The following programs are unaffected because they don't use OpenSSL to implement SSL:

• SSH (the protocol is not SSL)
• Chrome/Chromium (uses NSS)
• Firefox (uses NSS) (at least with Firefox 27 on Ubuntu 12.04, but not with all builds?

What is the impact?

The bug allows any client who can connect to your SSL server to retrieve about 64kB of memory from the server at a time. The client doesn't need to be authenticated in any way. By repeating the attack, the client can dump different parts of the memory in successive attempts. This potentially allows the attacker to retrieve any data that has been in the memory of the server process, including keys, passwords, cookies, etc.

One of the critical pieces of data that the attacker may be able to retrieve is the server's SSL private key. With this data, the attacker can impersonate your server.

The bug also allows any server that your SSL client connected to to retrieve about 64kB of memory from the client at a time. This is a worry if you used a vulnerable client to manipulate sensitive data and then later connected to an untrusted server with the same client. The attack scenarios on this side are thus significantly less likely than on the server side.

Note that for typical distributions, there is no security impact on package distribution as the integrity of packages relies on GPG signatures, not on SSL transport.

How do I fix the vulnerability?

Remediation of exposed servers

1. Take all affected servers offline. As long as they're running, they're potentially leaking critical data.

2. Upgrade the OpenSSL library package. All distributions should have a fix out by now (either with 1.0.1g, or with a patch that fixes the bug without changing the version number). If you compiled from source, upgrade to 1.0.1g or above. Make sure that all affected servers are restarted.
   On Linux, you can check if potentially affected processes are still running with grep 'libssl.*(deleted)' /proc/*/maps

3. Generate new keys. This is necessary because the bug might have allowed an attacker to obtain the old private key. Follow the same procedure you used initially.

   • If you use certificates signed by a certification authority, submit your new public keys to your CA. When you get the new certificate, install it on your server.
   • If you use self-signed certificates, install it on your server.
   • Either way, move the old keys and certificates out of the way (but don't delete them, just ensure they aren't getting used any more).

4. Now that you have new uncompromised keys, you can bring your server back online.

5. Revoke the old certificates.

6. Damage assessment: any data that has been in the memory of a process serving SSL connections may potentially have been leaked. This can include user passwords and other confidential data. You need to evaluate what this data may have been.

   • If you're running a service that allows password authentication, then the passwords of users who connected since a little before the vulnerability was announced should be considered compromised. Check your logs and change the passwords of any affected user.
   • Also invalidate all session cookies, as they may have been compromised.
   • Client certificates are not compromised.
   • Any data that was exchanged since a little before the vulnerability may have remained in the memory of the server and so may have been leaked to an attacker.
   • If someone has recorded an old SSL connection and retrieved your server's keys, they can now decrypt their transcript. (Unless PFS was ensured — if you don't know, it wasn't.)

Remediation in other cases

Servers that only listen on localhost or on an intranet are only to be considered exposed if untrusted users can connect to them.

With clients, there are only rare scenarios where the bug can have been exploited: an exploit would require that you used the same client process to

1. manipulate confidential data (e.g. passwords, client certificates, …);
2. and then, in the same process, connected to a malicious server over SSL.

So for example an email client that you only use to connect to your (not completely untrusted) mail provider is not a concern (not a malicious server). Running wget to download a file is not a concern (no confidential data to leak).

If you did that between 2014-04-07 evening UTC and upgrading your OpenSSL library, consider any data that was in the client's memory to be compromised.

References

• The Heartbleed Bug (by one of the two teams who independently discovered the bug)
• How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
• Does Heartbleed mean new certificates for every SSL server?
• Heartbleed: What is it and what are options to mitigate it?

To test if you're vulnerable go here: http://filippo.io/Heartbleed/

If you find that you are vulnerable update openssl and restart your webserver.