How do I determine whether I am affected?
If I'm affected, what do I need to do? Apparently upgrading isn't enough.
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
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
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:
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
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
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.
To test if you're vulnerable go here: http://filippo.io/Heartbleed/
If you find that you are vulnerable update
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.
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
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 (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?