[tech] OpenSSL "Heartbleed" Issues
Sam Moore
matches at ucc.asn.au
Thu Apr 10 11:44:16 WST 2014
Servers
-------
From #ucc I gather that [DAA] already updated all our servers.
But if you have a collocated machine you need to update your openssl
libraries yourself.
Desktops / Clients
------------------
Today in #ucc kronicd pointed out that clients can also be vulnerable,
and that since murphy (the IRC bot) wasn't restarted it was still
vulnerable. This isn't a huge deal because murphy shouldn't have
anything important in it's memory. I have restarted murphy and it is OK now.
Using the same tool from https://github.com/Lekensteyn/pacemaker, I have
found that (up to date) browsers such as iceweasel and chromium on
debian testing might also still vulnerable.
These clients only return 7 bytes, whilst the examples in the readme
return 65535. From what I understand they still shouldn't be doing that.
In terms of UCC machines, firefox on cabellera at least does this.
I am running `yum upgrade`, but it is Scientific Linux so I'm not too
hopeful (also note that the graphics drivers will break again as a result).
I'm running the test server on https://curious.ucc.asn.au
To save you setting up your own, I'm logging to
http://curious.ucc.asn.au/pacemaker.txt
The first entry is iceweasel 17.0.10, the second is wget 1.15, the third
is murphy (Supybot on mussel) after being restarted.
7 bytes doesn't seem like a huge problem but I really don't know what I
am doing here. Any comments?
More general issues
-------------------
What I understand of this bug is that a malicious client or server can
access arbitrary memory used by the other (if it is vulnerable).
But I don't understand exactly how this may have affected UCC, or
continue to affect us, in the unlikely event our servers were exploited
before someone updated them.
What advice, if any, should we give our members?
Eg: should we be recommending people change their passwords if they have
used https services such as webmail or the forum?
We are running an apache2 server, but the pages authenticate via the
ldaps server on mussel, which is a different protocol entirely. Does
this mean it is not possible for password related memory to have been
leaked via apache?
Probably the best explanation I've found so far:
http://superuser.com/questions/739427/how-to-use-the-internet-while-heartbleed-is-being-fixed
[SZM]
UCC Wheel Member
More information about the tech
mailing list