Differences between revisions 14 and 15
Revision 14 as of 2008-05-13 17:36:46
Size: 6177
Editor: ?StuartPrescott
Comment: add command to verify the gpg signature on dowkd.pl.gz
Revision 15 as of 2008-05-13 19:05:43
Size: 6152
Editor: ?StuartPrescott
Comment: Updated URL for DSA to security page rather than d-s-a list archive
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
In [http://lists.debian.org/debian-security-announce/2008/msg00152.html Debian Security Advisory 1571-1] In [http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory 1571]

In [http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory 1571] (New openssl packages fix predictable random number generator), the Debian Security Team disclosed a vulnerability in the openssl package that makes many cryptographic keys that are used for authentication (e.g. through SSH) or signing (e.g. web server certificates) potentially vulnerable.

End User Summary

The scope of the problem includes:

  • weak keys for both clients and servers (see section "Identifying Weak Keys below")
  • compromise of other keys or passwords that were transmitted over an encrypted link that was set up using weak keys. Note that this last point means that passwords transmitted over ssh to a server with a weak dsa server key could be compromised too; see the [http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html Debian project's reaction to this].

Identifying Weak Keys

Characteristics of potentially vulnerable keys:

  • generated since 2006-09-17
  • generated with etch, lenny or sid (sarge is not vulnerable)
  • generated using openssl, ssh-keygen (GnuPG and GNUTLS are not affected)

Additionally, some DSA keys may be compromised in the following situations:

  • key generated with broken openssl = bad
  • key generated with good openssl and used to ssh from a machine with bad ssl = bad
  • key generated with good openssl and used to ssh from a machine with good ssl = good

Applications/protocols known to use these keys:

  • openssh (both server and user keys)
  • OpenVPN
  • DNSSEC
  • key material for X.509

To fix this, first aptitude update && aptitude upgrade to install the new version of the openssl package (the vulnerability is fixed in openssl version 0.9.8c-4etch3 for etch and version 0.9.8g-9 for lenny/sid).

Then, regenerate and distribute any potentially vulnerable keys. Instructions for how to regenerate the keys for these applications are below. You can also test to see if keys are vulnerable using the dowkd.pl utility as described below.

OpenSSH (Server)

{{{ rm /etc/ssh/ssh_host_* dpkg-reconfigure openssh-server}}} Note that your users will see a "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" warning when they next log on to your ssh server because the key has changed. They will need to edit $HOME/.ssh/known_hosts to remove the offending line before continuing; checking that the key fingerprint is correct, of course. You can remove the key from known_hosts by running "ssh-keygen -R hostname"

Also, note that your existing ssh connections shouldn't be interrupted.

OpenSSH (Client)

You will need to have a list of the openssh keys that you currently have and where they have been copied to. For each key that is vulnerable: {{{ cd ~/.ssh ssh-keygen -t rsa -f filename ssh-copy-id -i filename hostname }}} Replacing rsa by dsa if you prefer dsa keys and replacing filename and hostname with appropriate values.

OpenVPN

BIND9

Testing keys using dowkd.pl

The security team has prepared a utility for you to test your keys to see if they have a fingerprint that matches a list of known-weak finger prints. Download [http://security.debian.org/project/extra/dowkd/dowkd.pl.gz dowkd.pl.gz ] ([http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg signature]):

{{{cd /tmp wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg --verify dowkd.pl.gz.asc gunzip dowkd.pl.gz }}}

/!\ Note that dowkd.pl produces many false positives and that the authors suggest that it may also produce false negatives. On that basis, you might decide that it is simply easier to regenerate your keys as described above.

Use dowkd.pl in the following ways:

SSH Server Host Key

Key is OK:

{{{ perl dowkd.pl host localhost # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 }}}

Key is weak: {{{ perl dowkd.pl host localhost # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 localhost: weak key localhost: weak key }}}

SSH User Key

To check one user (username):

perl dowkd.pl user username
/home/username/.ssh/authorized_keys:1: warning: unparsable line
/home/username/.ssh/authorized_keys:3: warning: unparsable line
/home/username/.ssh/authorized_keys:4: weak key
/home/username/.ssh/authorized_keys:5: weak key

Notes:

  • The complaints about lines 1 and 3 are because these lines are comment lines (starting with #) in the ~/.ssh/authorized_keys files (which are allowed, see man 8 sshd for the syntax).

  • Line 2 has a non-weak dsa key that should be replaced anyway according to the information provided above.
  • Lines 4 and 5 are rsa keys that are reported as being weak; the DSA doesn't mention rsa keys anywhere so it is not clear whether this is a false-positive from dowkd.pl or if these keys are also weak but this information is just not clearly communicated in the DSA.

Other keys?

  • someone who actually understands this tool and its output, please insert details here!

Technical Summary

(If you want to add more technical details that an end-user doesn't need to know or isn't likely to understand, please add them here rather than making the above summary impossible for the average user to understand.)

Causes

It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. This was done to try to make it easier to debug C applications that use the openssl libraries which is a good thing to do.

A discussion of why this change was made can be found at [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 #363516] and also on the [http://marc.info/?t=114651088900003&r=1&w=2 openssl-dev list] although it appears that a certain [http://www.links.org/?p=327 revisionist attitude] is being held with regards to that conversation.