[sf-lug] Heartbleed TLS/SSL bug

[Rick Moen]

Quoting Michael Shiloh (michaelshiloh1010 at gmail.com):

> (1) As I understand it, change passwords now, since many sites have
> already implemented fix, but to be really safe you have to change
> passwords continuously until all sites you visit have fixed this bug.
>
> Am I correct?

As is often the case in troubleshooting[1], the best place to start is
to first consider what problem you're trying to solve (and whether it's
the right problem).  In the case of a security problem, we often ask
(specifically) the related question 'What is the threat model?'

_If_ the Heartbleed OpenSSL bug is present on an SSL-oriented Web site
you exchange sensitive information with, then, until the vulnerable
OpenSSL software gets removed/replaced, malign parties can send RFC6520
SSL heartbeat requests to extract the server host's unencrypted memory
contents in 64 kB chunks as OpenSSL accesses that RAM.  That RAM
contents can be expected to include SSL cert private keys, user
username/password data (such as yours), session keys, other keypairs,
HTTP cookies, and a whole lot of other sensitive data that may be deeply
important to you.

Such extracted keys can also then be used to retroactively decrypt
streams of SSL-encrypted data you and the site have exchanged in the
past, if that session data has been captured while traversing the
Internet.  (That threat against past data transmissions will remain
_even_ if the site fixes the vulnerability and regenerates all relevant
keys, unless a precaution called 'Perfect Forward Security' has been
used until now.)

Getting back to a password change:  What is the threat model that
changing your site password would address, where the Heartbleed bug is
concerned?  Answer:  _If_ the site has had the bug until now and
has just fixed it, then changing your password will prevent intruders
from abusing your credentials they may have stolen using Heartbleed
before the site remedied its SSL problem.

If the site didn't have the Heartbleed bug, then changing your password
isn't expecially useful (at least, not on Heartbleed grounds).

If the SSL Web site _did_ have the Heartbleed bug but hasn't yet fixed
it, then your changing your site password will make any previously
stolen password invalid, which is good, _but_ your new password will be
easily stealable the exact same way.

How do you know whether a site has been running a buggy version of
penSSL in the two-year period since OpenSSL 1.0.1 came out (introducing
the buggy implementation of the RFC6520 SSL keepalive)?  If yes, how do
you know when that hole has been fixed?

Good questions.  I addressed that in the FAQ whose URL I posted last
night.  http://lists.svlug.org/archives/svlug/2014-April/058620.html


You know my favourite part about writing FAQs?  It's the bit where
people don't read them.  ;->

Just kidding.  Sort of.


> (2) As I understand it, vulnerable sites include those that we don't
> have to log into, and that the secrets they gather might include
> secrets relating to other sites.

It's the RAM contents in the vulnerabie sites instances (buffers and
such, accessed by OpenSSL), that can be stolen.

> In other words, if I avoid visiting my bank's website, and yet my
> bank's login credentials are in RAM for some reason, and I visit some
> other random site that has been compromised, that site could read my
> RAM and thus acquire the credentials to my bank.

Huh?  That sounds a little confused.

I _think_ your hypothetical loss scenario, about which you're asking, is
speculating that sensitive data might be stolen from the _client_
machine RAM -- in a situation where the vulnerable copy of OpenSSL
exists on the server.

If so, no.  The Heartbleed attack is one where carefully crafted RFC6520
keepalive calls are sent over SSL to a vulnerable OpenSSL instance,
explpiting a bug in vulnerable (1.0.1 through 1.0.1f) OpenSSL versions'
heartbeat implementations that permits prying sensitive data out of that
machine's RAM.  Which is not _your_ RAM.

Your Web browser doesn't use OpenSSL's libssl.so collection of TLS
library calls.  Firefox uses NSS.  Chromium/Chrome uses NSS, last I
heard.  Safari uses Apple's libsecurity_ssl (which has had its own
severe problems, http://www.imore.com/understanding-apples-ssl-tls-bug).
MSIE appears to use something called Security Support Provider (SSP).
Opera uses TLSLite.

That's not to say you cannot hurt yourself on the client side of an
https connection using tools that invoke a buggy OpenSSL.  That I
covered in a followup, last night, to my FAQ posting:
http://lists.svlug.org/archives/svlug/2014-April/058621.html




Jeff Bragg wrote:

> I believe it's only the server's RAM which is at risk.  The leak
> happens during heartbeat checks (assuming it wasn't compiled with that
> option turned off). I *think* this only applies to the server end of
> the transaction; as far as I know (and perhaps Rick can weigh in on
> this).

Jeff, in general, you are right (in practice) -- but nothing prevents
exploiting a client-side buggy copy of OpenSSL by sending it carefull
crafted keepalive traffic from the server end.  There is buggy
client-side software that links to and uses OpenSSL in that way, e.g.,
curl.  See:
http://lists.svlug.org/archives/svlug/2014-April/058621.html

> Using the check tools I included links for should help determine, for
> the most part, who has and hasn't upgraded (though I've found some
> sites don't respond properly to the first one, like ebay and
> linkedin).

Lots of false positives and false negatives have been found.  I referred
to that in my FAQ.


[1] In the role-playing game Paranoia, players can be promoted to
Troubleshooter, a job in which you are tasked with finding people who
are creating trouble, and shooting them.  Remember:  'The Computer is
your friend.  Trust the Computer.'

http://io9.com/5973846/why-the-paranoia-rpgs-alpha-complex-is-the-greatest-dystopia-of-all-time