Messages in this thread |  | | | Date | Thu, 13 Jan 2005 04:53:31 +0100 | | From | Marek Habersack <> | | Subject | Re: thoughts on kernel security issues |
| |
On Wed, Jan 12, 2005 at 10:25:06PM -0500, Dave Jones scribbled: [snip] > > Whatever. I happen to believe in openness, and vendor-sec does not. It's > > that simple. > > That openness comes at a price. I don't need to bore you with > analogies, as you know as well as I do how wide and far Linux > is deployed these days, but doing this openly is just irresponsible. > > Someone malicious on getting the announcement of a new kernel.org release > gets told exactly where the hole is and how to exploit it. > All they'll need to do is find a target running a vendor kernel before > updates get deployed. Whilst this is true to a certain degree > today, as not everyone deploys security updates in a timely manner > (some not at all), things can only get worse. That might be, but note one thing: not everybody runs vendor kernels (for various reasons). Now see what happens when the super-secret vulnerability (with vendor fixes) is described in an advisory. A person managing a park of machines (let's say 100) with custom, non-vendor, kernels suddenly finds out that they have a buggy kernel and 100 machines to upgrade while the exploit and the description of the vuln are out in the wild. They have to port their custom stuff to the new kernel, compile it, test it (at least a bit), deploy on 100 machines and pray it doesn't break. During all that time (and the whole process won't take a day or even two) the evil guys are far ahead of the poor bastard managing the 100 machines (since all they need is one exploit which will work on any of our admin's machines). One other factor that makes it hard for such a person to apply the patches is simply that there is no single place to find the security patches in. He goes to securityfocus.com, for instance, and what does he find? A nice description of the vulnerability, a discussion, a list of affected kernel versions and credits which usually list vendor advisories and kernel versions and very rarely a link to an archived mail message or a webpage with the patch. Hoping he'll find the fixes in the vendor kernels, he goes to download source packages from SuSe, RedHat or Trustix, Debian, Ubuntu, whatever and discovers that it is as easy to find the patch there as it is to fish it out of the vanilla kernel patch for the new version. Frustrating, isn't it? Not to mention that he might need to backport the fix, if he runs an earlier version of the kernel. And now assume that everything is as extremely open as Linus says - the admin has the same access to the exact information the vendors on vendor-sec have, together with the same fix they have (in form of a simple patch available without fishing for it all over the place). He starts the race with the bad guys exactly at the same time they start running looking for the vulnerable machines on the 'Net. Priceless, IMHO. I guess that, contrary to what you've just said above, hiding the information is irresponsible. Having said that, I don't think everything should be as extremely open as Linus would want it to see, but rather the way he proposed (and which many folks agreed to) with the 5-day (or so) embargo for the advisory release and with the patch(es)/discussion openly available to anyone interested (based on the premise that most people learn about vulnerabilities not from security lists but from security bulletins, tech news sites, user forums etc.)
best regards,
marek [unhandled content-type:application/pgp-signature] |  |