Debian/Ubuntu have added additional components to their openssh-* packages which detect (and, on the server side, reject) vulnerable SSH keys as a result of the broken random number generatation. http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1576 Given that such vulnerable keys might have been uploaded to *any* ssh-running OS, should similar detection be built into openssh directly? It would seem odd that as a result of this vulnerability becoming public that Debian and Ubuntu sshd servers are (once updated) *more* secure than those running on other OSes, because the Debian and Ubuntu servers now reject attempts to connect with those vulnerable keys. I've done some searching around this bugtracker and mailing list archives, but can't even find *discussion* of this issue. Alternatively, please tell me why such a modification to openssh would be a really bad idea - I can then refer to this bug in other contexts explaining why it isn't going to be done :-)
I think there is a considerable disadvantage to the implementation of this feature: users are liable assume any vulnerable key will be detected and rejected, which is likely a false assumption :( What certain distributions are including is not a complete list, their utilities/patches seem to analyze the first 80-84 bits of a fingerprint -- this is liable to give false positives, and the inclusive blacklists only cover the most basic permutations of key, a la; 1024-bit DSA 768-bit RSA 1024-bit RSA 2048-bit RSA As far as I am aware they don't cover 4096-bit RSA, and any user who had generated with `ssh-keygen -b 8150 -t rsa` would not be blocked. I think this might be a feature which needs to be maintained externally. That way there can be good documentation showing what permutations would be detected and users are less liable to make nasty assumptions... Perhaps another good reason to not include this is the 'bloat factor'? It'd probably make releases considerably larger?
> As far as I am aware they don't cover 4096-bit RSA, and any user who > had generated with `ssh-keygen -b 8150 -t rsa` would not be blocked. Sorry, perhaps I should clarify -- any user who has generated with a non-standard key length would not be covered and it would be computationally impossible to generate all 32767 permutations per architecture / word length vs. all possible key length possibilities.
Created attachment 1508 [details] blacklisting and ssh-vulnkey Here's the current patch we're using for this in Debian. I've tried to ensure that it can at least theoretically be acceptable on all systems, but am more than happy to work on this as necessary; I think it's important to deploy this as widely as possible. I believe that the blacklisting feature itself is separate from the distribution of the blacklist files. Those are, as observed, large, unwieldy from the point of view of distribution with OpenSSH, and not necessarily complete (although the published blacklists for each key type and size are complete with respect to this particular vulnerability). However, I can imagine other uses for the blacklisting code itself. For instance, a sysadmin responding to a compromised machine might want to use it as a quick way to lock out use of particular keys.
Created attachment 1510 [details] blacklist patch from Debian 1:4.7p1-12 Here's an updated version to align with the most recent Debian upload. Changes from the previous attachment: * Refactor rejection of blacklisted user keys into a single reject_blacklisted_key function in auth.c (thanks, Dmitry V. Levin). * Fix memory leak of blacklisted host keys (thanks, Dmitry V. Levin).
Created attachment 1529 [details] Support for key blacklisting based on compact binary encoding of partial fingerprints (e.g., under 4.5 bytes per 48-bit fingerprint); patch against 3.6.1p2, but is trivial to forward-port.
Created attachment 1530 [details] The blacklist encoder program - takes Debian's 32-hex-char one-per-line fingerprint lists as input
Created attachment 1531 [details] The blacklist checker program - can be used to test correctness of the encoding, etc.
I have attached the key blacklisting code from Openwall GNU/*/Linux (also used at least by ALT Linux). We've been using this "in production" on many systems for 2+ weeks with no issues (and have detected some weak keys "in the wild"). I am posting this primarily to have everything in one place. Also relevant are these URLs: http://www.openwall.com/lists/oss-security/2008/05/27/3 - the original announcement http://www.openwall.com/lists/oss-security/2008/05/27/4 - on forward-port to openssh-5.0p1 http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/openssh/ http://git.altlinux.org/people/ldv/packages/?p=openssh.git - repositories with these patches (and more) Compared to the Debian patch, this uses much smaller files (less than 4.5 bytes per key for 48-bit partial fingerprints), it's very fast (will work just fine on a VAX), it can be configured to be fail-close (in case of errors), and the size of partial fingerprints is not hardcoded anywhere (it's specified on "blacklist-encode" command-line, with no need to recompile anything, so an existing build of sshd that works with 48-bit fingerprints now will also work with, say, 64-bit just fine).
We didn't merge this at the time and there's little point doing so now.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1