Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

CVE-2014-0160 a.k.a. Heartbleed is a vulnerability in OpenSSL. It looks scary.

How do I determine whether I am affected?

If I'm affected, what do I need to do? Apparently upgrading isn't enough.

share|improve this question
They don't seem to do dogfooding. – Uwe Keim Apr 9 '14 at 5:26
No. It doesn't look scary. It looks pants-poopingly terrifying. – evamvid Apr 10 '14 at 0:05
up vote 91 down vote accepted

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.


share|improve this answer
"Generally, you're affected if you run some server where you generated an SSL key at some point." may mislead. To emphasize, if you generate your key on one server, and use it on another, you're in trouble if the server using it runs a vulnerable version of OpenSSL. – Matt Nordhoff Apr 8 '14 at 13:01
Client certs are also affected IIRC – Elazar Leibovich Apr 8 '14 at 13:40
@ElazarLeibovich Not client certs specifically (in fact client certificates are unlikely to be leaked by this bug), but any data in client memory if a client using a vulnerable library version connected to a malicious server using a protocol that supports server-initiated heartbeats. I asked experts about this, haven't had a clear answer yet. – Gilles Apr 8 '14 at 13:43
I think Firefox does use OpenSSL. If I run lsof -c firefox | grep 'ssl\|crypto', I get /usr/lib64/libssl.so.1.0.0, /usr/lib64/libcrypto.so.1.0.0, /lib64/libk5crypto.so.3.1, and /opt/firefox/libssl3.so. – user64707 Apr 8 '14 at 17:50
@B4NZ41 Just do the security upgrades. The advisory has been out for over 20 hours. – Gilles Apr 8 '14 at 22:28

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.

If you want to see how bad the exploit is; see here: https://github.com/nopejpg/Heartbleed

I removed all of the limitations the original author put into place allowing for full 64k dumps from the exploit.

share|improve this answer
as Gilles mentions in his answer, simply updating and restarting is not enough. you need to respond to the potential compromise of your private keys - the most basic requirement is revocation of those keys, but you also need to deal with information that could have been compromised using the key. like session IDs. – strugee Apr 12 '14 at 1:55

There is no way to recover from this bug. Save all logs, they will be needed in the event someone actually realized the vulnerability actually existed before it was announced

share|improve this answer

protected by Community Jun 2 '14 at 7:18

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.