HeartBleed: BALUG.org & SF-LUG.{org, com} NOT vulnerable

[Michael Paoli]

HeartBleed: BALUG.org & SF-LUG.{org,com} NOT vulnerable

For those that may be wondering if the BALUG.org and/or SF-LUG.{org,com}
sites are or were vulnerable to the HeartBleed OpenSSL security bug,
the answer is they are not and were not vulnerable.

Technical details:

BALUG
BALUG's hosts under the BALUG.org domain are running:
Debian GNU/Linux 6.0.x "Squeeze" ("oldstable")
One of those hosts is qemu-kvm guest which runs atop physical host:
"vicki"
see also references further below

SF-LUG
[www.]SF-LUG.{org,com} is qemu-kvm guest host running:
Debian GNU/Linux 6.0.x "Squeeze" ("oldstable")
that guest host runs on physical host "vicki"
see also references further below

"vicki":
physical host running:
Debian GNU/Linux 6.0.x "Squeeze" ("oldstable")
see also references further below

Debian GNU/Linux 6.0.x "Squeeze" ("oldstable")
Not vulnerable, see:
https://lists.debian.org/debian-security-announce/2014/msg00071.html
see also:
https://lists.debian.org/debian-security-announce/2014/msg00072.html

[Rick Moen]

Post by Michael Paoli
HeartBleed: BALUG.org & SF-LUG.{org,com} NOT vulnerable

Eh?

Reminder: The Heartbleed exploit is totally inappliable to Web servers
doing only ordinary HTTP.

https://www.balug.org/ doesn't appear to exist. Nor do
https://www.sf-lug.org/ or https://www.sf-lug.com/ -- or, at minimum,
the three currently ignore my browser queries. So: What SSL Web hosts
in those DNS domains _do_ exist, Michael? I can't remember any, so you
have me curious.
OpenSSL versions? Software linked to OpenSSL's TLS functions? FYI,
those functions are inside libssl.


But you reminded me of a joke making the rounds during 1996's BSE scare
about British beef.[1]

Two cows in southern England were discussing the morning BBC news.
One of them said 'Aren't you afraid of mad cow disease?' The second
replied 'Of course not. I'm a squirrel.'

[1] http://en.wikipedia.org/wiki/Bovine_spongiform_encephalopathy#The_ban_on_British_beef

[Michael Paoli]

Well, there is, e.g.:
https://secure.balug.org/wiki/doku.php?do=login
"secure" ... well, for certain versions of Snake Oil self-signed
cert, anyway. ;-) But it's better than passing all the wiki passwords
and such in the clear. It does - perhaps imperfectly, try to redirect
if one tries to access most of the wiki URLs that require authentication
to https
e.g. try here:
http://www.wiki.balug.org/wiki/doku.php
and click the Login button.
That, however, probably doesn't do things like cause the wiki to
set authentication cookies to SSL only (they're likely not - I haven't
checked). Can't do everything to protect users from themselves, but
can try and help them at least some wee bit.
And some of the domains do work with https (notwithstanding aforementioned
cert issues), e.g.:
https://www.archive.balug.org/
So, if some clients are using, e.g. HTTPS Everywhere, there may be some
(at least modest) security advantages offered on some of the domains.
But yes, it certainly doesn't cover them all. And thus far at present
[www.]balug.org and [www.]sf-lug.{org,com} don't offer https for those
hostnames/domains, though they may cover some other domains, and https
may be more generally available on them in future.

If one is curious, too, try this experiment. Hit e.g.:
https://www.sf-lug.org/
(or .com instead of .org, or optionally drop the leading www.)
but instead resolving to use the IP address secure.balug.org.
(e.g. temporarily alter one's resolution for those sf-lug names for
one's client - be sure to use the sf-lug name in the URL so the clinet
will set appropriate Host: header with the sf-lug name in it).

So, ... might not be much there ... but there is some https, etc., even
if only a wee bit. The HeartBleed OpenSSL bug also impacts clients, not
just servers - e.g. wget linked to vulnerable library can be exploited by
malicious server.

In any case, at least 4 hosts in total, and none of them vulnerable nor
were they vulnerable, to the HeartBleed OpenSSL bug (perhaps in part by
luck, but in any case).

Subject: Re: [BALUG-Talk] HeartBleed: BALUG.org & SF-LUG.{org, com}
NOT vulnerable
Date: Sat, 12 Apr 2014 17:03:35 -0700

Post by Michael Paoli
HeartBleed: BALUG.org & SF-LUG.{org,com} NOT vulnerable

Eh?
Reminder: The Heartbleed exploit is totally inappliable to Web servers
doing only ordinary HTTP.
https://www.balug.org/ doesn't appear to exist. Nor do
https://www.sf-lug.org/ or https://www.sf-lug.com/ -- or, at minimum,
the three currently ignore my browser queries. So: What SSL Web hosts
in those DNS domains _do_ exist, Michael? I can't remember any, so you
have me curious.

http://lists.balug.org/pipermail/balug-talk-balug.org/2014-April/005225.html
http://lists.balug.org/pipermail/balug-talk-balug.org/2014-April/005224.html

[Rick Moen]

Post by Michael Paoli
So, ... might not be much there ... but there is some https, etc., even
if only a wee bit.

Thanks for satisfying my curiosity -- because, you see, I'd never seen
mention of SSL Web services before for either BALUG or SF-LUG, and they
are nowhere mentioned (AFAICT) on the groups' Web sites.

I'm guessing, though, that none of the data sent either over or in
support of those HTTPS links is exactly security-sensitive. I'm also
guessing that the HTTPS variants of those URLs have seen _extremely_
little use.

If y'all want to encourage HTTPS for particular BALUG and/or SF-LUG
functions (e.g., wiki), you really ought to redirect to it to enforce
its use -- to to mention linking to them from the Web sites instead of
mentioning them nowhere.

Post by Michael Paoli
The HeartBleed OpenSSL bug also impacts clients, not
just servers - e.g. wget linked to vulnerable library can be exploited by
malicious server.

I already FAQed this a couple of days ago.
http://lists.svlug.org/archives/svlug/2014-April/058620.html
http://lists.svlug.org/archives/svlug/2014-April/058621.html

Latter link shows an example of wget linked against libssl, the portion
of OpenSSL that provides TLS functions. (FYI, it is also linked against
libcrypto, the other half of OpenSSL that is not at all implicated,
which is also the reason OpenSSH was unaffected, as it likewise calls
librcrypto but not libssl.)

The only client-side exploit I've seen so far is against /usr/bin/curl
(not, FWIW, wget) as linked to vulnerable libssl.

[jim]

SF-LUG.{com,org} is
* one hand-coded HTML static page that loads
a PHP script to update meeting date-time info
and a single image. It has a few links to other
web sites
* HTTP access
* no logging in
* loaded in a VM on a debian host

Post by Rick Moen

Post by Michael Paoli
So, ... might not be much there ... but there is some https, etc., even
if only a wee bit.

Thanks for satisfying my curiosity -- because, you see, I'd never seen
mention of SSL Web services before for either BALUG or SF-LUG, and they
are nowhere mentioned (AFAICT) on the groups' Web sites.
I'm guessing, though, that none of the data sent either over or in
support of those HTTPS links is exactly security-sensitive. I'm also
guessing that the HTTPS variants of those URLs have seen _extremely_
little use.
If y'all want to encourage HTTPS for particular BALUG and/or SF-LUG
functions (e.g., wiki), you really ought to redirect to it to enforce
its use -- to to mention linking to them from the Web sites instead of
mentioning them nowhere.

Post by Michael Paoli
The HeartBleed OpenSSL bug also impacts clients, not
just servers - e.g. wget linked to vulnerable library can be exploited by
malicious server.

I already FAQed this a couple of days ago.
http://lists.svlug.org/archives/svlug/2014-April/058620.html
http://lists.svlug.org/archives/svlug/2014-April/058621.html
Latter link shows an example of wget linked against libssl, the portion
of OpenSSL that provides TLS functions. (FYI, it is also linked against
libcrypto, the other half of OpenSSL that is not at all implicated,
which is also the reason OpenSSH was unaffected, as it likewise calls
librcrypto but not libssl.)
The only client-side exploit I've seen so far is against /usr/bin/curl
(not, FWIW, wget) as linked to vulnerable libssl.
_______________________________________________
BALUG-Talk mailing list
http://lists.balug.org/listinfo.cgi/balug-talk-balug.org

[Robert Beckerdite]

I am constantly amazed by the candor and technical level of the discussion at BALUG. Keep it up!

Robert Beckerdite

-----Original Message-----
From: balug-talk-bounces-nJFXYWEDAR/***@public.gmane.org [mailto:balug-talk-bounces-nJFXYWEDAR/***@public.gmane.org] On Behalf Of jim
Sent: Sunday, April 13, 2014 10:15 AM
To: balug-talk-nJFXYWEDAR/***@public.gmane.org
Subject: Re: [BALUG-Talk] What SSL Web hosts in those DNS domains _do_ exist? Re: HeartBleed: BALUG.org & SF-LUG.{org, com} NOT vulnerable


SF-LUG.{com,org} is
* one hand-coded HTML static page that loads
a PHP script to update meeting date-time info
and a single image. It has a few links to other
web sites
* HTTP access
* no logging in
* loaded in a VM on a debian host

Post by Rick Moen

Post by Michael Paoli
So, ... might not be much there ... but there is some https, etc.,
even if only a wee bit.

Thanks for satisfying my curiosity -- because, you see, I'd never seen
mention of SSL Web services before for either BALUG or SF-LUG, and
they are nowhere mentioned (AFAICT) on the groups' Web sites.
I'm guessing, though, that none of the data sent either over or in
support of those HTTPS links is exactly security-sensitive. I'm also
guessing that the HTTPS variants of those URLs have seen _extremely_
little use.
If y'all want to encourage HTTPS for particular BALUG and/or SF-LUG
functions (e.g., wiki), you really ought to redirect to it to enforce
its use -- to to mention linking to them from the Web sites instead of
mentioning them nowhere.

Post by Michael Paoli
The HeartBleed OpenSSL bug also impacts clients, not just servers -
e.g. wget linked to vulnerable library can be exploited by malicious
server.

I already FAQed this a couple of days ago.
http://lists.svlug.org/archives/svlug/2014-April/058620.html
http://lists.svlug.org/archives/svlug/2014-April/058621.html
Latter link shows an example of wget linked against libssl, the
portion of OpenSSL that provides TLS functions. (FYI, it is also
linked against libcrypto, the other half of OpenSSL that is not at all
implicated, which is also the reason OpenSSH was unaffected, as it
likewise calls librcrypto but not libssl.)
The only client-side exploit I've seen so far is against /usr/bin/curl
(not, FWIW, wget) as linked to vulnerable libssl.
_______________________________________________
BALUG-Talk mailing list
http://lists.balug.org/listinfo.cgi/balug-talk-balug.org