Considering dropping ssh-vulnkey from openssh-client
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 [cjwatson@debian.org]
Reply to: