| Summary: | Should sshd detect and reject vulnerable SSH keys (re: Debian DSA-1571 and DSA-1576) | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Dave Ewart <davee> |
| Component: | sshd | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | normal | CC: | alex.howells, cjwatson, djm, solar |
| Priority: | P2 | ||
| Version: | 5.0p1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | |||
|
Description
Dave Ewart
2008-05-25 06:13:25 AEST
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 |