[sf-lug] HeartBleed OpenSSL bug mini-Q&A

[Michael Paoli]

This is NOT intended to be anywhere near a full Q&A or FAQ!

I'll mostly just touch some select points I've not seen covered on the
SF-LUG list regarding HeartBleed (and pardons if I may have missed it -
I'm certainly not up-to-the-minute on my reading of that list).

Why bother stating whether or not SF-LUG and/or BALUG are or were
vulnerable or not?  Mostly a combination of: folks want to know if their
information was or may have been compromised, it's high
visibility/publicity security flaw, so there are a lot of folks,
including many also not technical, who want to now, "it's the right
thing to do" (at least approximately?), and perhaps most notably (also)
in reaction to lots of general (and relatively well founded) complaints
about vendors - and especially sites, not clearly stating if the are, or
most notably if they ever were, vulnerable.

"if they ever were, vulnerable" (to HeartBleed).  *Many* sites, are
quietly closing the vulnerability, but *not* informing their
customers/users that they *were* vulnerable and *may have been exposed*.
E.g. I've seen cases of major financial institutions that have brand
spanking new CA (re)issued SSL certs, but are completely silent on the
matter of HeartBleed.

Can you tell if a site *was* vulnerable, by noting that they have an SSL
cert with a very recent issue date?  No.  Most notably many CAs, when
reissuing an SSL cert, issue it not with a not valid before date of the
current date (or a date a day or two before reissue), but when reissuing
cert for replacement, give a not valid before date the same as the
earlier cert that's being replaced.

What code/libraries/binaries exactly are vulnerable?  The short version
is OpenSSL versions 1.0.1 - 1.0.1f  If it doesn't say that on the
version, I'm safe right?  Not necessarily.  Some, e.g. vendors, use
different version numbering.  Some may not even use OpenSSL or ssl in
their naming conventions.  If it compiled using the vulnerable code, and
without disabling the heartbeat extension, it is or may be vulnerable.
If it has version 1.0.1 thorough 1.0.1f I'm vulnerable, right?  Not
necessarily.  Some are patching and retaining those version numbers, so
patched versions may have same/similar version number and not be
vulnerable (e.g. for Debian "stable": 1.0.1e-2+deb7u5).  Also, some
code, e.g. OpenSSH, though linked with the vulnerable OpenSSL, wasn't
using the vulnerable parts of OpenSSL, thus OpenSSH is not and was not
vulnerable to HeartBleed.

Can I get a list of all vulnerable software and sites, or at least what
is known vulnerable and not or was, and test such, etc.?
See references.

"Should I change my password?"  I'm not going to get into the whole
debate about that, but I'll suggest some approximate algorithms I've
seen/heard, which I didn't (quite) see specifically mentioned on the
SF-LUG list (though there may have been links to such).  And I won't
cover passwords in general.  Anyway, algorithm I've at least
approximately heard:  For "high value" sites (e.g. on-line banking one
uses), unless the site was never vulnerable, change immediately, then
wait about 10 days (from the 2014-04-07 disclosures), then change
again.  And for that about 10+ days, keep a sharp eye out for any
fraudulent activities on the account(s), identity theft, etc.
(generally a best practice to at least periodically check for such
potential issues).  For all other sites, (e.g. medium/low value) one
may optionally use that same algorithm, or just wait some bit
(particularly if one has not used the site in about the past week or
so) - perhaps 10 to 30 days, and then change the password (or next time
one goes to use the site, whichever comes first - and if that's
rather/quite soon, one may want to change password again in about 10 to
30 days).  And a "best practice" - do at least occasionally change all
passwords anyway.  A bit of the rationale to some of those algorithms
relative to HeartBleed.  Prior to public disclosure (and even
relatively shortly - like a few days + or so), the probability of
exploit being used and data compromised is relatively low (few if any
attacks in the wild).  Public disclosure was 2014-04-07, exploits in
the wild quickly ramped up.  Most any major site by about 2014-04-09 or
so, if it was vulnerable, it was likely being exploited by then.  So,
if one's most recent use of site was << 2014-04-07, it is improbable
one was compromised.  2014-04-07--~2014-04-09 or so, for high(er) value
sites/targets, if one used them in that time frame and they were
vulnerable when used, it's rather to highly probable the site was being
actively exploited, and one's data *may* have been compromised.  By
about 2014-04-09 or so, most all "high value" sites were no longer
vulnerable.  Lots of the medium / low value sites - may not be so quick
to patch/update and close the vulnerability - so one might be exposed
for longer on there.  So, hopping on "too fast" to change one's
password, particularly on site one's not used in some fair while, may
be counter-productive to one's own security (e.g. may expose new
password where old hadn't been exposed).  ("DON'T PANIC" - is generally
good advice :-))

OpenSSH? - Not vulnerable.  Uses vulnerable library, but not the
vulnerable part(s) of the vulnerable library.

What's exposed, clients too?  Up to 64 KiB (less one byte?) of memory
of the process (however that may often contain quite juicy bits),
what's in there at any given time is somewhat random, but the
vulnerability can be exercised repeatedly, often giving different extra
bits each time (and probably more so with more busy active sites).  And
clients?  Yes, clients are likewise vulnerable too.  From what I've
seen, looks like server exploits were out there "in the wild" (at least
in quantity) before client exploits, but client exploits are also out
there (with perhaps a one or two day lag - if that - following server
exploits).  More details (and accuracy/specificity) - see additional
references.

When was I first notified of it?
2014-04-07T21:36:46+0000 [2014-04-07 14:36:46 PDT]
https://lists.debian.org/debian-security-announce/2014/msg00071.html

When was that bug first introduced?
To the OpenSSL source:
2011-12-31T22:59:57+0000
2011-12-31T14:59:57-0800

Other mitigating factors?
One I'll mention - forward secrecy, see, e.g.:
https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-forward-secrecy
That doesn't protect for this particular HeartBleed vulnerability.
However it does protect from cracker getting https server's secret key
and then using it to decrypt earlier captured https session traffic.

More information?
Many have put out good/excellent information, including e.g. some of
Rick Moen's earlier links, e.g.:
http://lists.svlug.org/archives/svlug/2014-April/058620.html
et. seq.
One of the best sources of technical information and details I've seen
on it has been from SANS.  E.g. they've some excellent webcasts (now
archived) well covering it, plus additional materials and information
(e.g. Internet Storm Center (ISC).  See, e.g. (note one needs be
registered, etc., to view the webcasts):
https://isc.sans.edu/forums/diary/Heartbleed+vendor+notifications/17929
(see also the follow-up comments on that post)
https://www.sans.org/webcasts/openssl-heartbleed-vulnerability-98105
https://www2.sans.org/webcast/recording/citrix/98105/18160
https://www.sans.org/webcasts/heartbleed-vulnerability-2-98130
https://www2.sans.org/webcast/recording/citrix/98130/18190
https://www.sans.org/webcasts/side-heartbleed-clientside-heartbleed-vulnerabilities-explained-98135
https://www2.sans.org/webcast/recording/citrix/98135/18440
Some of that SANs material also has good/excellent advice information
on, among other things, what to tell
customers/clients/users(/mom/grandma), prioritization of handling, what
*not* to do, etc.  There's also some quite good stuff in there that's
rather Linux-specific (notably ensuring some key bits for making sure
one has closed the vulnerability on a host that's remains up and
running throughout - bit more on that in a post to follow from me).