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.

Improve this question
7
  • Fix for Ubuntu: apt-get update && apt-get install openssl libssl1.0.0 && service nginx restart; then, reissue your private keys
    – Homer6
    Apr 8, 2014 at 20:45
  • Use this tool to detect the vulnerable hosts: github.com/titanous/heartbleeder
    – Homer6
    Apr 8, 2014 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 9, 2014 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 9, 2014 at 19:37
  • 1
    I'm sure that's what @JasonC meant, but +1 for making it explicitly clear.
    – Craig Tullis
    Apr 9, 2014 at 21:38

6 Answers 6

Reset to default
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?.

Improve this answer
2
  • 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 8, 2014 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 8, 2014 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

Improve this answer
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 9, 2014 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, 2014 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

Improve this answer
1
  • 4
    Specifically it exploits the TLS connection that is established after the "starttls" command, if I read the code correctly.
    – Perseids
    Apr 8, 2014 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/

Improve this answer
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.

Improve this answer
2
  • 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, 2014 at 3: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, 2014 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.

Improve this answer

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