Bugzilla Bug 221759

As discussed on vendor-sec, the PRNG in Debian and Ubuntu is generating key
pairs from a very small key space. This mostly affects openvpn, and openssh.
This problem does not directly affect Gentoo, our ssl library does not include
the weakness. But Gentoo systems might be affected if users with SSH keys
generated on a Debian/Ubuntu after 2006 are allowed to login.

Ubuntu is preparing a patch to implement blacklisting known vulnerable keys
inside sshd. I believe we should include that patch in our openssh ebuild as a
precautionary measure.

The blacklist feature is introduced with (parts of) this patch:
http://patches.ubuntu.com/o/openssh/openssh_1:4.7p1-10ubuntu1.patch

Since Gentoo is only indirectly affected, and there are tools to check for the
existence of bad keys, this is rather an enhancement. Base-system, what are
your thoughts on that?

i'm having a hard time picking out what the changes are based on that patch ...
it looks like it's a patch against Debian's patched version of openssh

what exactly is the behavior of the proposed changes ?  some program to scan
for keys ?  the sshd actively ignoring weak keys ?  a warning when you login ?

The blacklist feature (still haven't found the actual blacklist on the Ubuntu
site yet) will refuse people logging in with known weak keys. I haven't found a
readable patch yet.

infra would be interested in something like this.  Ideally, it would be
controllable via sshd_config to do nothing, warn, or refuse.

exactly ... i dont want a patch that simply disables all keys that are weak. 
if your root key happens to be weak, then upgrading ssh just locked you out. 
that's no good.

packages.debian.org has an openssh blacklist package

btw, for infra purposes, ive setup a cronjob on most of my machines that scan
all ssh keys with the dowkd.pl script the debian guys have ... any user found
with a weak key gets an e-mail and their key deleted :)

Sorry, my fault. The patch does not actually introduce this feature yet.

Here's the blacklist:
http://security.debian.org/debian-security/pool/updates/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

Here's the ChangeLog:
openssh (1:4.7p1-9) unstable; urgency=critical

  * Fill in CVE identifier for security vulnerability fixed in 1:4.7p1-8.
  * Mitigate OpenSSL security vulnerability (CVE-2008-0166):
    - Add key blacklisting support. Keys listed in
      /etc/ssh/blacklist.TYPE-LENGTH will be rejected for authentication by
      sshd, unless "PermitBlacklistedKeys yes" is set in
      /etc/ssh/sshd_config.
    - Add a new program, ssh-vulnkey, which can be used to check keys
      against these blacklists.
    - Depend on openssh-blacklist.
    - Force dependencies on libssl0.9.8 / libcrypto0.9.8-udeb to at least
      0.9.8g-9.
    - Automatically regenerate known-compromised host keys, with a
      critical-priority debconf note. (I regret that there was no time to
      gather translations.)

 -- Colin Watson <cjwatson@debian.org>  Tue, 13 May 2008 12:33:38 +0100



And here's the (huge) diff:
http://ftp.debian.org/debian/pool/main/o/openssh/openssh_4.7p1-9.diff.gz

(In reply to comment #6)
> btw, for infra purposes, ive setup a cronjob on most of my machines that scan
> all ssh keys with the dowkd.pl script the debian guys have ... any user found
> with a weak key gets an e-mail and their key deleted :)
> 

care to share how you did it?  It seems like a reasonable solution until this
sshd blacklist patch is available.

#!/bin/sh

export PATH=/usr/local/bin:${PATH}

users=$(
    dowkd.pl -c /var/cache/dowkd.db file /home/*/.ssh/authorized_keys 2>&1 | \
    grep weak | \
    sed \
        -e 's:^/home/::' \
        -e 's:/.*::'
)
for u in $users ; do
    rm -f /home/$u/.ssh/authorized_keys 
    cat <<-EOF | mail -s "weak Debian key detected in your account" $u
    One of your ssh keys on `hostname` has been found to be weak.

    For more information, please review:
    http://lists.debian.org/debian-security-announce/2008/msg00152.html

    Your key has been automatically removed.
    EOF
done

Created an attachment (id=153175) [details]
openssh_4.7p1-blacklist.patch

The original Debian blacklist patch, extracted from "openssh_4.7p1-9.diff.gz"
and resynced against Gentoo's "openssh-4.7_p1-r6"

Created an attachment (id=153177) [details]
openssh_1:4.7p1-10ubuntu1-blacklist.patch

Ubuntu's bugfix patch, excerpt from openssh_1:4.7p1-10ubuntu1.patch

so the info doesn't get lost:  This is how to generate a line for the blacklist
file:

ssh-keygen -l -f some_key.pub | awk '{print $2}' | cut -d ':' -f 7- | sed -e
's/://g'

one fingerprint per line, the file sorted.

vapier:  any chance we can get these patches in? maybe use-flag based?

*** Bug 222233 has been marked as a duplicate of this bug. ***

vapier, do you have plans to include the patch? Judging from comments here and
on the duplicate, there is some user request.

Hi,

I confirm : this is a strong user request, since our gentoo servers are vulne

See the discussion in
http://thread.gmane.org/gmane.comp.security.oss.general/409

(In reply to comment #15)
> I confirm : this is a strong user request, since our gentoo servers are vulne

Hubert, Please clarify what you mean buy what are our servers vuln

I second this request - I think blacklisting would be a handy feature to have.
On our server, we had at least one user with Debian-generated keys, and it took
me a while to cobble together a script to check them (didn't look here first,
unfortunately :-). In any case, you also wouldn't want to authenticate against
a server with a weak host key, so blacklist warnings would be good here, too.
To put things into perspective: a weak key has about the same entropy as a
alphanumeric password of a whopping three characters (case-insensitive).

Florian

For anyone curious, CVE-2008-2285 has been assigned to the issue fixed by
openssh_1:4.7p1-10ubuntu1-blacklist.patch.

> Hubert, Please clarify what you mean buy what are our servers vuln

Sorry, made a mistake while typing, and didn't notice that my message was not
complete.

My situation is the following : a few unix servers on which nearly 2000
students work. Some of these students generated their key with "compromised"
openssl engines (ubuntu...). For those users I ran dowkd, and disabled their
key "manually". But, since our openssh servers do not have a blacklisting
function, I will have to nighlty run this manual check, to avoid future users
with compromised keys to authenticate with ?

Integrating the blacklist directly in the openssh server would probably be the
most practical solution I think ? Or maybe we have another way to deal with
this problem ? Maybe it should be discussed with the openssl dev team ?

Cheers,

Hubert.

*** Bug 223149 has been marked as a duplicate of this bug. ***

Created an attachment (id=154917) [details]
openssh-5.0p1-blacklist.patch

ive added openssh-blacklist to the tree (but needs arch testing)

this patch is from Owl/Alt ... you can just add to openssh-5.0_p1.ebuild:
epatch "${FILESDIR}"/${PN}-5.0p1-blacklist.patch #221759

if people can test, i imagine i'll add as USE=blacklist ... the default
behavior is to allow blacklisted keys but warn ... in the future we can adjust
to reject

i wasnt kidding when i said i'm not adding this until i get feedback

Feedback: patch WFM, but the config file could use a commented out entry for
IgnoreBlacklistErrors, and the manpage claims the default for this option to be
version, while the default really is all (as you said above, just to remind
people). Oh, and a rdepend like "blacklist? ( net-misc/openssh-blacklist )"
would be good, too.