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.
I had to google what "heartbeat extension" does:<p><pre><code> 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.
</code></pre>
<a href="https://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-01" rel="nofollow">https://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-01</a><p>Edit: here is the commit patching the bug <a href="https://github.com/openssl/openssl/commit/7e840163c06c7692b796a93e3fa85a93136adbb2" rel="nofollow">https://github.com/openssl/openssl/commit/7e840163c06c7692b7...</a>
"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.<p>[0] <a href="http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04" rel="nofollow">http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04</a>
Ouch. Does this mean almost every Debian 7 web server out there is probably vulnerable to having its private data for supporting HTTPS compromised?<p><a href="https://security-tracker.debian.org/tracker/CVE-2014-0160" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2014-0160</a><p>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.<p>Would any of our resident security experts like to suggest best practices under such circumstances?<p>(Edit: It looks like the page I linked above has been updated and a patch is going into Wheezy security as I write this.)<p>(Edit 2: Confirmed that Wheezy security updates now include openssl 1.0.1e-2+deb7u5 and related libssl changes.)
Apparent introduction of the bug: <a href="https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3" rel="nofollow">https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f...</a>
Unfortunately, if you have been using an AWS ELB to terminate SSL traffic, they are vulnerable to this particular exploit. See this forum post: <a href="https://forums.aws.amazon.com/thread.jspa?threadID=149690" rel="nofollow">https://forums.aws.amazon.com/thread.jspa?threadID=149690</a>
Check for the extension:<p><pre><code> $ 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
</code></pre>
This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.
If your site is protected by CloudFlare (like HN is), you are automatically protected from this vulnerability (see: <a href="http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities" rel="nofollow">http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab...</a>).
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.
Are Android or iOS affected? Android seems to ship openssl 1.0.<p>Could a malicious server attack clients? Perhaps expose a browser's cookie jar or other saved passwords in memory?<p>The number of installed openssl clients across all devices and computers must be quite large.
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?
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.<p>(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.)
If you'd like to update the keg-only OpenSSL brew on osx, and dont care for legacy and crap:<p><pre><code> ( 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 )
</code></pre>
Beware, that by default on osx/ios, pretty much everything links to sketchy CommonCrypto or a crusty, quasi-deprecated 0.9.8.