[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 05 Mar 2013 08:11:21 +0100
From: Andreas Ericsson <ae@....se>
To: oss-security@...ts.openwall.com
CC: Eric Lacombe <goretux@...il.com>
Subject: Re: handling of Linux kernel vulnerabilities
Hi list. I work for a sub-vendor who ships one of the major distros as
part of an appliance. Just thought I'd chip in with my €0.02.
On 03/04/2013 10:12 PM, Eric Lacombe wrote:
> Hi,
>
> Le lundi 4 mars 2013 11:48:58, Greg KH a écrit :
>> On Sun, Mar 03, 2013 at 10:39:30PM -0500, Michael Gilbert wrote:
>>> I was getting encouraged by the recent anger-centric posts, the "what
>>> is it that we're supposed to do better?" ones. That gave me some
>>> encouragement that there was the possibility of positive change, but
>>> the "we're not going to make users more unsafe by telling them about
>>> issues affecting them" is a persistence of the denial state. That
>>> logic completely violates the known idiom that knowledge is power:
>>> give users the knowledge that they need to protect themselves, and
>>> they will; starve them of that knowledge, and they remain vulnerable.
>>
>> That's a load of crap.
>>
>> Seriously, you know it only benefits the "bad guys" if I were to say,
>> "This patch just went into Linus's tree that fixes a security problem
>> that you can exploit in this manner". No user would have a chance to
>> fix their systems before the vulnerability was added to the
>> "ultra-sploit" tool and everyone would have their systems trashed.
>
> I think there's a difference between disclosing the vulnerability and
> disclosing it with a related exploit. The first one allows to fulfill what
> Michael Gilbert explains without the consequences that you focus on.
>
Writing and testing an exploit for a "usable" security issue takes all of
an hour or two. Coming up with a proper patch, testing it, packaging it
and releasing it to users takes at least a week, and I personally think
that's erring optimistically.
For parts of a system that really *can't* be disabled without making the
system completely unusable (kernel, glibc and to some extent ssh tools),
I think a longer shush-time than "time of commit" is suitable for full
disclosure announcement. Note "announcement" here. People who're really
interested can ofcourse see in the patch and commit-message how the bug
can be triggered.
Otoh, where workarounds can be applied that prevent the bug from happening
the issue, I believe protection information should be released immediately.
Writing exploits (or test-cases) from workaround information is a *lot*
harder than from full disclosure listings.
--
Andreas Ericsson andreas.ericsson@....se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
