On Saturday, September 14, 2013 22:49:13 Colin Watson wrote: > 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.
In the course of some research I was doing recently I recall running across a survey that someone had done about SSH keys in use on the internet. My vague recollection (it was completely tangential to what I was looking for) was that it found that something like 0.04% of current internet visible keys were vulnerable. If that were true, would that change your plans any (i.e. is it worthwhile for me to try and find this again)? Scott K -- 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/5390339.vWLLJmp7uf@scott-latitude-e6320
