65

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.

T. Zengerink
  • 199
  • 5
  • 13
Flup
  • 7,688
  • 1
  • 31
  • 43
  • Fix for Ubuntu: apt-get update && apt-get install openssl libssl1.0.0 && service nginx restart; then, reissue your private keys – Homer6 Apr 08 '14 at 20:45
  • Use this tool to detect the vulnerable hosts: https://github.com/titanous/heartbleeder – Homer6 Apr 08 '14 at 20:47
  • 1
    `apt-get update` should be enough for Ubuntu now without downgrading, the patch appeared in the main repository last night. – Jason C Apr 09 '14 at 13:38
  • 10
    apt-get update is NOT enough. update only shows the latest changes, apt-get UPGRADE will apply then after the update. – sjakubowski Apr 09 '14 at 19:37
  • 1
    I'm sure that's what @JasonC meant, but +1 for making it explicitly clear. – Craig Tullis Apr 09 '14 at 21:38
  • @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. – Jason C Apr 09 '14 at 21:40
  • "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. –  Apr 11 '14 at 02:20

6 Answers6

40

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?.

Community
  • 1
Rob Moir
  • 31,664
  • 6
  • 58
  • 86
  • 3
    "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 Apr 08 '14 at 13:12
  • 6
    @Perseids you're right of course, I was trying to find a easily understandable way of saying that people aren't secure because they're running this version of webserver X or that version of SMTP server Y. I'm making an edit that will hopefully improve things, so thanks for pointing that out. – Rob Moir Apr 08 '14 at 13:22
35

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

Community
  • 1
simme
  • 451
  • 3
  • 2
  • 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. – Thomas Weller Apr 09 '14 at 21:18
  • 1
    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. – larsr Apr 10 '14 at 13:28
4

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

Martijn
  • 833
  • 1
  • 6
  • 10
  • 4
    Specifically it exploits the TLS connection that is established after the "starttls" command, if I read the code correctly. – Perseids Apr 08 '14 at 13:22
3

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/

Peter
  • 131
  • 3
3

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.

Nowaker
  • 281
  • 3
  • 10
  • 2
    Anything that links with libssl and uses TLS. Openssh uses openssl but doesn't use TLS, so it's not affected. – StasM Apr 10 '14 at 03:50
  • 2
    @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. – Nowaker Apr 10 '14 at 13:07
1

Other services are affected by this.

For anyone who uses HMailServer, start reading here - http://www.hmailserver.com/forum/viewtopic.php?f=7&t=26276

Anyone and everyone will need to check with the developers of all software packages to find out if updates are needed.

tiker
  • 11
  • 1