Re: thoughts on kernel security issues

[Marek Habersack <grendel@caudium.net>]

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

On Thu, Jan 13, 2005 at 05:06:52PM -0500, Dave Jones scribbled:
> On Thu, Jan 13, 2005 at 10:48:14PM +0100, Marek Habersack wrote:
>  
>  > > If admins don't install updates in a timely manner, there's
>  > > not a lot we can do about it.  For those that _do_ however,
>  > > we can make their lives a lot more stress free.
>  > Indeed, but what does have it to do with a closed disclosure list? 
> 
> For the N'th time, it gives vendors a chance to have packages
> ready at the time of disclosure.
I've heard that N times, too. I'm just failing to see that this justifies
the existence of that list and that's why I'm asking for other arguments.

>  > With open
>  > disclosure list you provide a set of fixes right away, the admins take them
>  > and apply. With closed list you do the same, but with a delay (which gives
>  > an opportunity for a "race condition" with the bad guys, one could argue).
>  > So, what's the advantage of the delayed disclosure?
> 
> Not having to panic and rush out releases on day of disclosure.
Releasing it a month later doesn't remove the rush and panic of the _users_
who are paniced and rush to install the freshly released kernels.

> Not having users vulnerable whilst packages build/get QA/get pushed to mirrors.
They are vulnerable all the time since the "internal" disclosure to the
public one. What makes you think that keeping things secret on the list
won't allow the bad guys to discover the vulnerability? As Linus said, they
are probably _more_ motivated than the good guys.

> Users of kernel.org kernels get to build and boot in under an hour.
> Vendor kernels take a lot longer to build.
Come on, it's just a matter of throwing in more hardware to that process.

> 1- More architectures.
>    (And trust me, there's nothing I'd like more than to be able
> 	to increase the speed of kernel builds on some of the architectures
> 	we support).
I realize that. In Debian we support a few very slow architectures. But,
let's not fool ourselves, the slow architectures aren't nearly as popular as
x86 or x86_64, ppc.

> 2- More generic, ie more modules to build.
If speed is an issue, I guess a vendor can afford getting 5 ARM/m68k/8086
(:) machines and distribute the build across them.

> In the case of public disclosure of issues that we weren't aware of,
> it's a miracle that we get update kernels out on day of disclosure
> in some cases. (In others, we don't, and the same applies to other vendors too)
Looking from the vendor point of view, you are perfectly right. Looking from
the user point of view, the user is as exposed with the closed list and new
vendor kernels released as with the open list and immediate disclosures. In
both cases it's a sort of a miracle for a user not to be hacked. Remember
the recent php problem? Before we knew, many, many, many sites were hacked -
even though the release with fixes was out. I don't know whether those
vulnerabilities were known to vendor-sec before that but if they were, the
delay didn't do a thing to make the situation better. Simply, no difference
- as far as I am concerned, the only argument so far for the existence of
the totally closed list is that "vendors must have time to build
kernels/software", as you wrote above. Not nearly enough of a reason, IMHO.

regards,

marek

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