Re: Considering dropping ssh-vulnkey from openssh-client
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
Reply to: