I'm considering removing ssh-vulnkey in an upload of the Debian openssh package sometime soon, and would like feedback.
What is ssh-vulnkey? -------------------- I wrote ssh-vulnkey as part of the set of countermeasures implemented in Debian and Ubuntu to mitigate http://www.debian.org/security/2008/dsa-1576. It is described here: http://manpages.debian.net/cgi-bin/man.cgi?query=ssh-vulnkey&manpath=Debian+7.0+wheezy The patch that adds ssh-vulnkey to OpenSSH also modifies ssh, ssh-add, and sshd to refuse to load blacklisted keys, either host keys or user keys; in the cases of ssh and sshd there is an option to downgrade this refusal to a warning, although that option is off by default. This was an important part of the response to that vulnerability, and I'm satisfied that it did its job. However, that was five years ago. Why remove it? -------------- As time passes, the chances that this code is actually any use to anyone diminish. DSA-1576 was announced while etch was stable, so we've had three stable releases since then; any keys that haven't been replaced with that much encouragement probably never will be, and although I have no way to measure it I think it likely that there are very few left. I've been gradually ramping down the extent to which this checking is integrated in openssh over the years. In July 2011 I dropped openssh-server's dependency on openssh-blacklist to a recommendation (#622604). In November 2012 I dropped it further to a suggestion, believing that we no longer need the blacklists installed by default. In May 2013 I removed the maintainer script code that forcibly regenerated vulnerable host keys on upgrade. I've had no complaints about any of these steps as far as I can recall - indeed, I don't appear to have had any mail about ssh-vulnkey at all since February 2010 - and I think it's time to take the next step and remove it entirely. The patch that adds ssh-vulnkey and the various bits of integration is the second-largest patch in the Debian openssh package. It frequently causes merge conflicts on upgrades (which I appreciate is only really a problem for me), but more importantly it's not really something I have occasion to test very much these days, and it touches sufficiently important parts of OpenSSH that I'm concerned that one of these days somebody is going to make a mistake when merging a new upstream version and introduce a vulnerability. The risk isn't particularly high and obviously anyone merging a new upstream version of OpenSSH is going to be pretty careful, but it's more risk than not carrying the patch at all. We would still need to carry a small patch to silently ignore the old configuration options, but that's comparatively trivial and would go right next to other similar patches we're stuck with anyway. What if somebody generates a new vulnerable key by accident? ------------------------------------------------------------ This is of course theoretically possible. It's only on the order of hundreds of times less likely than somebody randomly generating the key of a Debian developer and thus being able to compromise our project machines using it. If we thought that this sort of probability was worth worrying about then we wouldn't be using public-key cryptography. We might be concerned about people digging old vulnerable keys out of long-term storage; but that's only a problem if they're still allowed to authenticate to anything, and sysadmins have had the option of running "ssh-vulnkey -a" to scan for authorized_keys files mentioning vulnerable keys for the last five years. If they haven't, then it would not surprise me to find that the relevant accounts have long since been compromised anyway. Could ssh-vulnkey be moved to a separate package? ------------------------------------------------- There is the option of dropping the ssh/ssh-add/sshd integration code, and moving ssh-vulnkey to its own source package where it can largely be ignored but could be used by sysadmins to check user keys. However, ssh-vulnkey uses various code from OpenSSH proper (such as key parsing code) which is not exposed in shared library form, so doing this would probably require at least a partial rewrite. While I'm not particularly opposed to this, my opinion is that the demand at this point is likely to be very low, and I have no interest in doing that work. If there's strong feeling in that direction then I suggest that somebody else should take up that project. I would note that the ssh-vulnkey binary has fairly lightweight linkage requirements (OpenSSL, zlib, and libc), so it would not be particularly horrible for a sysadmin who really felt they needed it to take a copy of the last available version of it and run that. As I say, I'm sceptical that this would be worth bothering with in reality. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130914214913.gl...@riva.ucam.org
