To get more information on the effects of the heartbeat vulnerability in OpenSSL 1.0.1 - 1.0.1f see http://heartbleed.com/
Check your installed version with
openssl version -a. OpenSSL 0.9.8 is not vulnerable. OpenSSL 1.0.2 betas and later branches may not have received a patch yet, be careful if you need to use these versions. (1.1, etc.) On Linux (for example Debian or Ubuntu) be sure to check the distribution for backports! You can get a hint if you’re facing a backport by looking at the build date. Anything newer than 2014-04-07 is a good candidate.
Sample output on OS X with MacPorts OpenSSL 1.0.1g:
1 2 3 4 5 6
There are a few ways to test your TLS enabled service:
- A Python script with STARTTLS support. hb-test.py by @_takeshix
- Another Python script without STARTTLS support. ssltest.py by Jared Stafford
- The Heartbleed Test Website by @filosottile
If you get an output of
TLS server extension "heartbeat" (id=15), len=1 your server is likely affected.
Keep in mind that these test tools aren’t mature yet (obviously) and may report false positives or false negatives.
The use of forward secrecy ciphers seems to mitigate this mostly. Specific TLS sessions still may be affected if the session key has been leaked at that time. All recorded non-forward-secrecy traffic can be decrypted in retrospect.
If you find
libssl 1.0.1-1.0.1f anywhere you need to upgrade that library immediately!
The version of
libssl used by OS X.
The version of
libssl used by MacPorts.
You can check if any binary on OS X dynamically links against
If you get a line about
libssl you then need to check which specific version that OpenSSL library uses with the strings command as shown. If you do not get any
libssl info but you know that a binary makes use of TLS/SSL then you need to check for statically linked libraries. Some binaries give you that info by passing
-V as the only argument.
If you can recompile that binary update OpenSSL and link against that. If you don’t have the sourcecode to that software contact the vendor. If that is not possible as well, stop using that software now.
Where to go from here
Then rebuild all the binaries on your machine that link against OpenSSL. Restart all services that use those binaries. When in doubt do a full restart.
Now the really fun part starts. Generate new keys for als SSL/TLS secured services. You may want to use this “opportunity” to upgrade your key length. Changing keys is necessary independently of your certificate authority in use. This also applies if you use self-signed certificates as the private keys themselves may be compromised.
Get new certificates for all the new keys and revoke the old certificates.
For secondary vulnerabilities see http://heartbleed.com/ and act accordingly. Yes, this likely means changing a lot of passwords (again), deleting cookies, invalidating OAuth tokens, etc.
MacPorts already has an updated openssl package thanks to maintainer Markus W. Weißmann (mww).
1 2 3
Check that your OpenSSL library is the correct one:
Then check for packages that depend on OpenSSL.
To upgrade all packages that depend on OpenSSL
Then restart all services that you have just upgraded. This may for example be Apache or nginx.
Long term “fun” with this bug
A few ideas of devices that are likely to stay vulnerable for a long long time.
- Firewall/plastic router web interfaces which rarely get updates if at all
- Printers which get even less upates will be vulnerable for years to come
- Tesla anyone?
- any kind of appliance
- especially embedded boxes
- network switches
- Your fridge
- home automation systems
- APIs that nobody ever looks at
- iOS Apps that use OpenSSL