
OpenSSL Security Advisory: TLS heartbeat read overrun - moonboots
http://www.openssl.org/news/secadv_20140407.txt
======
tptacek
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
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
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](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...](https://github.com/openssl/openssl/commit/7e840163c06c7692b796a93e3fa85a93136adbb2)

------
nly
"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](http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04)

~~~
iso8859-1
Here's the commit for the fix:
[http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...](http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3)

~~~
osivertsson
Ouch, pretty basic lack of bounds checking.

Even though the code got better with this fix I still wouldn't accept code
that looks like this in a review. Why are 1, 2, 3, 16 not defines? What's up
with the code duplication between files? Where are the unit-tests?

I'm starting to feel that a lot of software that has been around for 10+ years
and is commonly used does not live up to current best practices regarding
writing good system-level software.

~~~
rlpb
> I'm starting to feel that a lot of software that has been around for 10+
> years and is commonly used does not live up to current best practices
> regarding writing good system-level software.

I get the impression that this applies to openssl far more than other
software. The code base is a mess, _and_ it's security sensitive. So people
dare not touch it.

It's a shame that there isn't a better incentive for this particular code base
to be fixed.

------
gry
"Heartbleed Bug" Q&A: [http://heartbleed.com/](http://heartbleed.com/)

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

~~~
snewman
It's already at the top of the homepage, as a separate submission.

~~~
gry
It is now. It wasn't at the time of vacri's post. Top of the homepage is best.

------
Silhouette
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](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
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.

~~~
0x0
I think startssl requires $$$$ to revoke and/or reissue those "free" certs
before they expire :-/

~~~
StefanWallin
Is there another good CA that doesn't charge $$$ for both issuing and
revocations?

~~~
0x0
I just got a revocation request accepted with no charge there.

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

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

~~~
cperciva
A lot of people are doing spiped-like things using stunnel.

~~~
midas007
Basically, for internal infrastructure, where autossh wont work and/or where
something simpler than ssh is desired.

So the strawmen arguments about it not replacing TLS is not the point.

stud, nginx, stunnel, f5 load balancers and cloudflare will still be needed
for now, until 'moxie0 or someone comes up with a viable CA alternative AND
something way, way simpler than TLS (brain-hurt ASN1, even with Wireshark).

------
tlrobinson
Apparent introduction of the bug:
[https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f...](https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3)

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

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

------
redbeard0x0a
Unfortunately, if you have been using an AWS ELB to terminate SSL traffic,
they are vulnerable to this particular exploit. See this forum post:
[https://forums.aws.amazon.com/thread.jspa?threadID=149690](https://forums.aws.amazon.com/thread.jspa?threadID=149690)

------
jvehent
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
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...](http://www.seobook.com/download-alexa-
top-1-000-000-websites-free)

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

------
grittygrease
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...](http://blog.cloudflare.com/staying-ahead-of-
openssl-vulnerabilities)).

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

~~~
extrapolate
Not entirely correct, as the blog post states: > We fixed this vulnerability
last week before it was made public.

Although there's still the other 103 weeks this was vulnerable to worry about.

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

~~~
ars
Debian already updated:
[http://www.debian.org/security/2014/dsa-2896](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/](http://www.ubuntu.com/usn/usn-2165-1/)

------
0x0
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
Yes, the vulnerable code is used by both client and server so any client using
openssl is affected.

~~~
biafra
Which parts of Android really use OpenSSL to do TLS with this heartbeat
feature enabled?

The browsers? All Apps running on Dalvik? All apps running on ART?

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

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

~~~
specto
Make sure you check running daemons too... apt-get install debian-goodies;
checkrestart

------
ceejayoz
Is this something I have to worry about as someone who uses AWS ELB SSL
offloading? Hard to tell from the docs.

~~~
trapexit
Yes.
[https://forums.aws.amazon.com/thread.jspa?threadID=149690](https://forums.aws.amazon.com/thread.jspa?threadID=149690)

~~~
nicpottier
Note that until it gets patched, you can go to your ELB config and disable TLS
support, which I believe (someone please correct me if not) will protect you
from this particular attack. Whether the cure is better than the disease is up
to you.

~~~
ccpost
Disabling TLS in the ELB config seemed to work for me until AWS finishes the
patch rollout. (Looks like they're partway on the rollout.)

------
anaphor
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
I don't think ASLR helps here one single bit.

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

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

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

------
zurn
Go C!

Hope everyone had forward secrecy on by now.

------
ctz
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
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
of course, anyone using 0.9.8 is fine.

