Re: thoughts on kernel security issues

[Marek Habersack <grendel@caudium.net>]

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]