| Summary: | net-misc/openssh blacklist feature for known weak keys (CVE-2008-0166) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Robert Buchholz (RETIRED) <rbu> |
| Component: | Auditing | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | anigel, base-system, bertrand, echtler, gentoo-bugs, gentoo, infra-bugs, lars, natanael.copa, ps |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://thread.gmane.org/gmane.comp.security.oss.general/409 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
openssh_4.7p1-blacklist.patch
openssh_1:4.7p1-10ubuntu1-blacklist.patch openssh-5.0p1-blacklist.patch |
||
|
Description
Robert Buchholz (RETIRED)
2008-05-11 23:08:12 UTC
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 attachment 153175 [details, diff]
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 attachment 153177 [details, diff]
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 attachment 154917 [details, diff]
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. |