[Gllug] Debian / Ubuntu SSL vulnerability

[Philip Hands]

On Wed, May 14, 2008 at 09:00:33AM +0100, John Winters wrote:
> > Eeek.
> >
> > "It is strongly recommended that all cryptographic key material which
> > has been generated by OpenSSL versions starting with 0.9.8c-1 on
> > Debian systems is recreated from scratch. Furthermore, all DSA keys
> > ever used on affected Debian systems for signing or authentication
> > purposes should be considered compromised"
> >
> > 	http://www.debian.org/security/2008/dsa-1571
> > 	http://www.ubuntu.com/usn/usn-612-1
> >
> > That's a whole lot of extra work I could have done without. Ho hum.
> > Time to start regenerating those keys...
> 
> I've seen lots of articles describing how to take steps to fix your keys,
> and others describing what the coding error is, but I've yet to find
> anything which describes in detail what the danger is.  Can anyone
> elaborate?
> 
> There's a big difference between, "Anyone can walk into any system running
> ssh" and "Sniffing an extended ssh session would allow someone to crack
> your key quite easily".
> 
> Say one had an isolated system running ssh and a weak key stored on it as
> an authorised key.  Without any further information, could a black hat now
> gain access to that system?  How easily?

I can tell you what we spent yesterday doing to the debian.org servers,
and you can decide how far you want to go down the same path.

First off, we disabled all authorised_keys access to all servers.

We've also reset everyone's passwords.

We've rebuilt all ssh_host_rsa_keys that were not obviously too old to
be affected, and removed all ssh_host_dsa_keys (and removed mention of
them from sshd_config)

We're rebuilding all X.509 certs (for https, imaps, pops etc.)

Of all those things, the authorised_keys lockdown is most vital where
any of your keys are young enough to be affected, and were generated
on the right sorts of host (note, if you're running sarge today, you're
not touched by this)

The reason for this is that the bug has resulted in ssh-keygen only
creating 32k unique keys, so an attacker who knows your account name can
get in without needing a password by generating that list of 32k keys,
and trying them out on you.  If you happen to use key based authentication
to give direct root access, then they don't have to try too hard to
guess that user name. (Finally, a decent example to back up the argument
for using sudo from a normal user account instead ;-)

The rest of the threat is mostly about session sniffing.  Given that all
your sessions will have been using a very poor source of entropy, anyone
who's been sniffing your network is only a small step away from having the
plain text.  That exposes all the passwords you've typed via ssh.  It also
happens to reveal the keys for dsa (hence our dumping of those keys) and
the keys used for SSL connection (hence our recreation of all such keys)

So you should lock down your systems until you've confirmed that your ssh
keys are either old enough, were not generated on the relevant versions
of Debian (or derived) distros, or you've recreated them.

You should then upgrade all the systems that might be affected before
doing any further fixups, as your typing almost in the clear if you're
connected to a system with this bug.

Then recreate potentially weak ssh-rsa keys, and discard/recreate _all_
ssh-dsa keys.

Then, change all your passwords that have been typed over dodgy sessions,
and recreate all openssl keys.

Then check the details of the DSA/USN to see what I've forgotten ;-)

Note that OpenVPN has also been hit by this, at least in the key
generation bit.  I'm not certain if using strong keys on a system with
this weakness exposes the session data, but it's probably safest to
assume it does.

I think that's about it -- there is apparently a version of ssh in
unstable that has a blacklist of the broken keys that will stop people
using them in future, but that doesn't help with the historical exposure
of session data, and X.509 (SSL) certificate data.

Cheers, Phil.

P.S.  If people are tempted to indulge in finger-pointing about this,
I should mention that while this bug only affects Debian (and our
derivers), it seems that Kurt was hunting bugs when he put this patch in,
and that he checked with openssl-dev at the time:

  http://marc.info/?t=114651088900003&r=1&w=2

so trying to lay all the blame at his door, or asserting that it's due
to Debian not talking to our upstreams is not justified IMO.
--
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug