WingNews logo WingNews
top | item 7548468

OpenSSL Security Advisory: TLS heartbeat read overrun

297 points| moonboots | 12 years ago |openssl.org

85 comments

order

tptacek|12 years ago

Ugh, that's a horrible vulnerability. We found something similar in nginx a few years ago, and the result is that you can repeatedly open up client connections and dump server memory as it changes, revealing keys and, without any real effort, authentication info and cookies.

conformal|12 years ago

not sure what you have to maintain, but it sure sucks having to scramble and fix this right away.

our (quick) fixes are almost all done:

- recompile openssl where necessary (web, chat, mail, windows binaries) without heartbeat support

- roll related certs and keys ASAP

and then comes the painful process of suggesting all web service users roll their certs and auth.

oh, and rotate personal passwords at other sites that issue a warning about openssl...

dmix|12 years ago

I had to google what "heartbeat extension" does:

   DTLS is designed to secure traffic running on top of unreliable
   transport protocols.  Usually such protocols have no session
   management.  The only mechanism available at the DTLS layer to figure
   out if a peer is still alive is performing a costly renegotiation.
   If the application uses unidirectional traffic there is no other way.

   TLS is based on reliable protocols but there is not necessarily a
   feature available to keep the connection alive without continuous
   data transfer.

   The Heartbeat Extension as described in this document overcomes these
   limitations.  The user can use the new HeartbeatRequest message which
   has to be answered by the peer with a HeartbeartResponse immediately.
https://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-01

Edit: here is the commit patching the bug https://github.com/openssl/openssl/commit/7e840163c06c7692b7...

nly|12 years ago

"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code.

[0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04

hackinthebochs|12 years ago

I've been thinking along these lines for a long time now, that parsing is such a critical activity that we should treat it with far more reverence than we do. Ideally, we would define languages to describe the format of the data that we want to parse (something like a BNF perhaps), and the OS/environment would parse it and populate variables/provide a dictionary in response. Ensuring that the input to your algorithm is exactly as expected is such a critical task that no one should ever be doing it manually.

zurn|12 years ago

> "Don't roll your own parsers" should really be up there with "Don't roll your own crypto".

.. and if you do, don't do it in a highly memory-unsafe language. Espcially when it's for a security critical piece of central internet infrastructure!

gry|12 years ago

"Heartbleed Bug" Q&A: http://heartbleed.com/

vacri|12 years ago

Can we please vote this link higher? It's got a ton of information in it.

Silhouette|12 years ago

Ouch. Does this mean almost every Debian 7 web server out there is probably vulnerable to having its private data for supporting HTTPS compromised?

https://security-tracker.debian.org/tracker/CVE-2014-0160

If so, that must be an awful lot of web servers, with a horrendous cost for everyone to buy new certificates etc. if there's no reliable way to determine what if anything was compromised.

Would any of our resident security experts like to suggest best practices under such circumstances?

(Edit: It looks like the page I linked above has been updated and a patch is going into Wheezy security as I write this.)

(Edit 2: Confirmed that Wheezy security updates now include openssl 1.0.1e-2+deb7u5 and related libssl changes.)

rwg|12 years ago

All reasonable certificate authorities will — at no cost — revoke your existing certificate and issue you a new certificate with the same expiration date as your old certificate. You'd just need to send the CA a new certificate signing request created from a newly-generated RSA key pair.

If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should find a less horrible CA to throw your money at.

cperciva|12 years ago

In case anyone was wondering why I wrote spiped...

FiloSottile|12 years ago

Totally agreed on the over-complexity and un-securability of TLS, that too often is deployed where something simpler should be used instead.

However, wouldn't OpenSSH be the thing spiped replaces most of the times? And that has a better security track record (I mean, better than OpenSSL for sure).

peterwwillis|12 years ago

Well, since you mention it, why did you write spiped? It seems like if you just wanted to protect network services from the internet you could have A) segmented your network, B) used ssh, C) used one of the myriad other existing non-TLS tunneling protocols. Doing A might expose you to less risk than B or C, since with tunnels if your client is owned your server is still vulnerable. Of course if you just wanted to code something for fun I totally understand that too. But it seems like there were already alternatives to stunnel (and I don't really get why people use stunnel to begin with)

drdaeman|12 years ago

But isn't spiped mostly irrelevant here?

I mean, it's not a TLS replacement, as it's based on PSK (thus only useable between two mutually trusting peers like me and myself), not PKI.

mappu|12 years ago

So they managed to notify Cloudflare in advance, but not debian/ubuntu security teams?

justizin|12 years ago

They may have had someone involved in the research / identification and fix.

jvehent|12 years ago

Check for the extension:

    $ echo -e "quit\n" | openssl s_client -connect google.com:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
    TLS server extension "heartbeat" (id=15), len=1
This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.

dmix|12 years ago

I wrote a bash script to check the top 1000 websites and huge percentage of them responded with heartbeat extension (30-40%):

  INPUT=websites.csv
  OLDIFS=$IFS
  IFS=,
  [ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }
  while read rank website
  do
    echo "checking $website for heartbeat..."
    echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
  done < $INPUT
  IFS=$OLDIFS
You can download a list of top 1 million websites from Alexa and Quantcast: http://www.seobook.com/download-alexa-top-1-000-000-websites...

Chinese websites timeout on port 443 so you'll have to skip them.

mpetrov|12 years ago

Keep in mind that you have to run this with OpenSSL v1.0.1 and above. Running it on a stock OS X Mavericks install will not detect the extension because v0.9.8 of OpenSSL is installed.

claudius|12 years ago

At least in my Bash (4.2.25(1)), there seems to be a difference between "2>&1|" and "2>&1 |" – the latter works as expected, whereas the former doesn’t give any output.

   $ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
   $ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1 | grep 'TLS server extension "heartbeat" (id=15), len=1'
   TLS server extension "heartbeat" (id=15), len=1
   $
Does anybody know why?

grittygrease|12 years ago

If your site is protected by CloudFlare (like HN is), you are automatically protected from this vulnerability (see: http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab...).

ars|12 years ago

You are protected now. But you were not before, so if any attacker figured this out before the public disclosure then you have [possibly] already been attacked and compromised.

amalcon|12 years ago

This is perhaps somewhat misleading. It's possible that this bug was being actively exploited before now, so you should change your keys even if you use a CDN (all the majors have already fixed this as far as I'm aware).

smtddr|12 years ago

Perhaps Cloudfare should note that the "up to 64kB" isn't entirely correct.

http://heartbleed.com/

>>There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

michh|12 years ago

An Ubuntu update would be nice right about now. Outside of disabling everything that uses openssl or compiling a new one manually, there's not much I can do to secure my servers at this moment. Meanwhile, I'm guessing a lot of not so nice people are racing to scan IP ranges for this bug.

atmosx|12 years ago

FreeBSD updated (run the update about 40 minutes ago).

0x0|12 years ago

Are Android or iOS affected? Android seems to ship openssl 1.0.

Could a malicious server attack clients? Perhaps expose a browser's cookie jar or other saved passwords in memory?

The number of installed openssl clients across all devices and computers must be quite large.

welder|12 years ago

Yes, the vulnerable code is used by both client and server so any client using openssl is affected.

hrrsn|12 years ago

OpenSSL doesn't seem to be installed on my jailbroken iPhone.

zrail|12 years ago

How does one go about installing this update on Ubuntu? "sudo apt-get upgrade openssl" didn't do it.

Andys|12 years ago

The fix has now been released by Ubuntu, so you can upgrade via the normal methods (apt-get update && apt-get upgrade)

vajorie|12 years ago

By either compiling & installing it with -DOPENSSL_NO_HEARTBEATS or waiting for the security fix to be backported by ubuntu devs. http://heartbleed.com/

rlpb|12 years ago

See: http://www.ubuntu.com/usn/usn-2165-1/

The binary package name is "libssl1.0.0". You want "sudo apt-get update && sudo apt-get install libssl1.0.0", but I suggest that you take all security and regular updates (or set sources.list to security only updates if you insist). Then you can just run "sudo apt-get update && sudo apt-get dist-upgrade" to pick up all updates, without worrying about package names.

If you want to verify if a particular vulnerability is fixed, look in /usr/share/doc/<package>/changelog.Debian.gz. In this case, you want /usr/share/doc/libssl1.0.0/changelog.Debian.gz. In this file, you'll see CVE-2014-0160 mentioned as fixed, which is the universal identifier of this vulnerability.

anaphor|12 years ago

If one were using ASLR would this have mostly mitigated this? (I just rebuilt without the heartbeat extension but I'm curious). Also how exploitable is this?

mpyne|12 years ago

I don't think ASLR helps here one single bit.

ccpost|12 years ago

I've been running the exploit against our test app (through AWS ELB), and have managed to get a fair bit of data out. Got snippets from HTTP requests on other threads including session cookies and even login passwords.

FiloSottile|12 years ago

It should really be possible to easily detect what functionalities your deploy of OpenSSL is using and recompile only those.

acqq|12 years ago

Anybody knows if the bug can be triggered in OpenSSH (I believe it uses the same lib?)

mbq|12 years ago

Most likely no since SSH is a different protocol than TLS.

zurn|12 years ago

Go C!

Hope everyone had forward secrecy on by now.

ctz|12 years ago

I wonder how many service providers with big OpenSSL deployments (cloudflare, google, facebook, etc.) will do the sane thing and roll their authenticity keys. I'm guessing zero.

(Assuming they are deployed in such a way that their long-term authenticity keys are in the memory space of the network service, and not kept on another system or HSM.)

midas007|12 years ago

If you'd like to update the keg-only OpenSSL brew on osx, and dont care for legacy and crap:

     ( export CONFIGURE_OPTS='no-hw no-rdrand \
       no-sctp no-md4 no-mdc2 no-rc4 no-fips no-engine'; \
  brew install https://gist.github.com/steakknife/8228264/raw/openssl.rb )
Beware, that by default on osx/ios, pretty much everything links to sketchy CommonCrypto or a crusty, quasi-deprecated 0.9.8.

dijit|12 years ago

of course, anyone using 0.9.8 is fine.