Ben Laurie wrote about the Debian SSL problem a couple of weeks ago. That particular post has attracted a huge response which is well worth reading if you care about free open source software and/or privacy/security issues (or even if you don’t). The key point to take from the discussion is that about two years ago the Debian development team “fixed” a perceived problem in openssl and in so doing actually introduced a fairly serious vulnerability. The net result of this change was that anyone using Debian or a related distribution such as Ubuntu to generate a cryptographic key based on the “fixed” opensssl libraries actually left themselves open to compromise. To quote from the Debian advisory “the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable…….. affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections.”
Fortunately, it seems that GPG keys are not affected (and in any case, my own key was generated some time ago and not on a Debian based system) but this is pretty serious nonetheless and means that a great many people (myself included) have been relying on keys which it turns out are vulnerable to attack. I have now regenerated all the keys I suspect were vulnerable, but that does not leave me feeling very comfortable about past usage.
I don’t want to denigrate the Debian team in any way, but I can’t help but agree with Ben Laurie’s view that the proper place to fix any perceived flaw in an open source product, particularly one as important as a security critical component, is in the upstream package – not in the distribution.
2 comments
Hi Mick,
Whilst I am not happy with what happened here in Debian the patch in question was actually discussed on the openssl-dev list *before* being applied. Ben now tries to claim that the openssl-dev list isn’t for openssl development, but as this LWN article points out the list was described on their site as:
The list he suggested to be used was not mentioned on their website. So I suspect there’s a bit of face saving going on here on their part too.. :-)
Also don’t forget that if you’ve used a compromised client with a good DSA key then you should consider that DSA key compromised as well. :-(
Chris
I agree that Ben may have been indulging in a bit of post facto “face saving” as you say. But he has the decency to mention the openssl-dev list posting – embarrassing as that may be. But that still doesn’t change my view that the upstream package maintainer is best placed to fix flaws.
Both sides of the argument look bad here. The openssl team for not providing sufficient support to a query about the code (and for not commenting the code sufficiently well to allow the researcher to understand the impact of commenting out the “offending” lines); and the Debian team for making and then maintaining a fork of the openssl code for two years without getting it back into the upstream.
Mick