OpenSSL Security Advisory: TLS heartbeat read overrun (opens in new tab)

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

Here's the commit for the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

2011-12-31, it looks like, so it's been there for a couple of years already (introduced between 1.0.0f and 1.0.1):

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

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.

> "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!

Looks like a good use case for Hammer: https://github.com/UpstandingHackers/hammer

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

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.

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

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)

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.

But it's written in C. So it can't be good!

(Sorry, I'm just still pissed at HN's simple mindedness and try to get more downvotes: https://news.ycombinator.com/item?id=7549916)

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

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.

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.

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?

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.

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

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.

Debian already updated: http://www.debian.org/security/2014/dsa-2896

Ubuntu should follow really soon, if not already.

Edit: Ubuntu updated: http://www.ubuntu.com/usn/usn-2165-1/

Looks like this being made publicly listed, they did get this CVE out now (I last checked that link around noon PST) http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...

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

It seems that Android has dodged this bullet by compiling OpenSSL with NO_HEARTBEATS: https://twitter.com/agl__/status/453472368589942785

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

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

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

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

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.

Yes. https://forums.aws.amazon.com/thread.jspa?threadID=149690

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

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.

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

of course, anyone using 0.9.8 is fine.