Heartbleed: are services other than HTTPS affected?

Question

The OpenSSL 'heartbleed' vulnerability (CVE-2014-0160) affects webservers serving HTTPS. Other services also use OpenSSL. Are these services also vulnerable to heartbleed-like data leakage?

I'm thinking in particular of

• sshd
• secure SMTP, IMAP etc -- dovecot, exim & postfix
• VPN servers -- openvpn and friends

all of which, on my systems at least, are linked to the OpenSSL libraries.

Solution 1

Any service that uses OpenSSL for its TLS implementation is potentially vulnerable; this is a weakness in the underlying cyrptography library, not in how it's presented via a web server or email server package. You should consider all linked services vulnerable to data leakage at least.

As I'm sure you're aware, it's quite possible to chain attacks together. Even in the simplest attacks it's perfectly possible to, for example, use Heartbleed to compromise SSL, read webmail credentials, use webmail credentials to gain access to other systems with a quick "Dear helpdesk, can you give me a new password for $foo, love CEO".

There's more information and links in The Heartbleed Bug, and in another question maintained by a Server Fault regular, Heartbleed: What is it and what are options to mitigate it?.

Solution 2

It seems your ssh-keys are safe:

It's worth pointing out that OpenSSH is not affected by the OpenSSL bug. While OpenSSH does use openssl for some key-generation functions, it does not use the TLS protocol (and in particular the TLS heartbeat extension that heartbleed attacks). So there is no need to worry about SSH being compromised, though it is still a good idea to update openssl to 1.0.1g or 1.0.2-beta2 (but you don't have to worry about replacing SSH keypairs). – dr jimbob 6 hours ago

See: https://security.stackexchange.com/questions/55076/what-should-one-do-about-the-heartbleed-openssl-exploit

Solution 3

In addition to the answer of @RobM, and since you ask about SMTP specifically: there already is a PoC for exploiting the bug on SMTP: https://gist.github.com/takeshixx/10107280

Solution 4

Anything that links with libssl.so may be affected. You should restart any service that links with OpenSSL after you have upgraded.

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u
bacula-fd: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/php/modules/openssl.so
python2: /usr/lib/libssl.so.1.0.0
python2: /usr/lib/python2.7/lib-dynload/_ssl.so
python: /usr/lib/libssl.so.1.0.0
ruby-timer-thr: /usr/lib/libssl.so.1.0.0
ruby: /usr/lib/libssl.so.1.0.0

Courtesy of Anatol Pomozov from Arch Linux mailing list.

Solution 5

Yes those services can be compromised if they rely on OpenSSL

OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software.

For a more detailed write up on the vulnerabilities, affected operating systems etc. you can checkout http://heartbleed.com/

View more solutions

Comments

[Homer6]

Fix for Ubuntu: apt-get update && apt-get install openssl libssl1.0.0 && service nginx restart; then, reissue your private keys

[Homer6]

Use this tool to detect the vulnerable hosts: github.com/titanous/heartbleeder

[Jason C]

apt-get update should be enough for Ubuntu now without downgrading, the patch appeared in the main repository last night.

[sjakubowski]

apt-get update is NOT enough. update only shows the latest changes, apt-get UPGRADE will apply then after the update.

[Craig Tullis]

I'm sure that's what @JasonC meant, but +1 for making it explicitly clear.

[Jason C]

@sjakubowski Well yes, of course; I presume (hope?) one knows how to apply system updates properly (the comment was following Homer6's earlier comment), but +1 for making it clear. :) The point is that the downgrade to 1.0.0 is no longer necessary.

[Admin]

"secure SMTP, IMAP etc" - yes. And SPDY too. Anything that uses OpenSSL and TLS for the socket security. "OpenVPN, OpenSSH, etc" - no, they are different protocols.

[Perseids]

"this is a weakness in the underlying system, not in how it's presented via a higher level system such as SSL/TLS" - No, that is wrong. It is a weakness in the implementation of the TLS heartbeat extension. If you don't ever use TLS you are safe. I do agree with your conclusion, though, that you have to be very careful in your analysis in what might be affected because of chained attacks.

[Perseids]

Specifically it exploits the TLS connection that is established after the "starttls" command, if I read the code correctly.

[Thomas Weller]

Isn't it indirectly affected as stated by @RobM? Someone reads root's password from memory using the Heartbleed vulnerability, gets whatever non-SSH access to the system and then steals the SSH stuff.

[StasM]

Anything that links with libssl and uses TLS. Openssh uses openssl but doesn't use TLS, so it's not affected.

[Nowaker]

@StasM That's why I wrote may be affected, not is affected. Also, OpenSSH server does NOT link against OpenSSL at all. Utilities like ssh-keygen do, but they are not used by OpenSSH server itself. Which is clearly visible in the lsof output I provided - OpenSSH is not listed there, although it's running on the server.

[larsr]

You can't read ANY 64k of memory with this bug, only 64k near where the incoming packet is stored. Unfortunately a lot of goodies tend to be stored there, such as decrypted HTTP requests with plaintext passwords, private keys, and pictures of kittens.