Andy Smith wrote:
> On Sat, Sep 26, 2009 at 06:43:18PM +0100, Damian Brasher wrote:
>> The Google security team announcement on the 13th September will have had a
>> negative impact on Open Source communities, like any accident does, but it
>> seems that lessons ought to be learnt.
>
> They first disclosed it to vendor-sec which is supposed to be a
> private list where such bugs are discussed and the timescales for
> public announcement are agreed. Unfortunately someone leaked the
> information and an exploit appeared in the wild.
>
> The Google employees concerned did not just announce it publicly.
>
> http://www.linux.com/news/software/linux-kernel/34926-linux-2631-rc6-released
> :
> "What was perhaps an interesting (if trivial) detail is that
> if it hadn't been for vendor-sec apparently leaking like a
> sieve, we'd have delayed the fix until the next -rc due to
> trying to be polite to vendors.
>
> So this may be one of the few time I'm actually happy about
> vendor-sec (even if it's because it failed to work the way
> it's supposed to ;), since I heartily dislike embargoes.
>
> [...]
>
> Linus"
You get the feeling that any help from a well organised scientific security
team is welcomed by Linus.
>> A simple model could be:
>>
>> 1) Security vulnerability found.
>> 2) Developer(s) contacted privately before announcement is made public.
>> 3) Developer fix privately forwarded to major vendors.
>> 4) Major vendors generate patch and make it available.
>> 5) Public announcement is made.
>
> Unfortunately "developer(s)/vendor(s)" is a large group of people
> and it inevitably leaks.
>
> Additionally, many vendors handle reports badly, and various Linux
> vendors and even sometimes the Linux kernel developers have at times
> passed off potential code execution bugs as "denial of service" just
> because at first glance it looks like all you can do is crash the
> kernel. When a changelog appears with such a "denial of service"
> fix in it, this draws attention to exactly what the bug was and it
> has happened before that code execution has been possible after all.
>
> http://lwn.net/Articles/191080/ :
> "Reading the description above, some system administrators
> may feel that there is no particular urgency in applying
> this update. The risk that a rogue user would fill up a disk
> with core dump files may seem small, so an update fixing the
> problem - and which requires a system reboot to be effective
> - can maybe be deferred for a while. After all, the Linux
> kernel core dump code takes pains to avoid overwriting files
> with core dumps, so the real potential for harm is small.
> It's a denial of service bug.
>
> Except that it's not. All that is required is to create a
> program containing a string in the format understood by
> cron, send it over to /etc/cron.d, and use the bug to create
> a core dump there. Eventually cron will wander along,
> helpfully pick the line it understands out of the
> surrounding binary junk, and execute (as root) the commands
> found there. It is a simple and straightforward local root
> exploit; an example implementation has been posted to the
> full-disclosure list."
>
> So at every level there is potential for non-malicious (accident,
> incompetence, ...) mistakes to be made. I would suggest this
> happens far more often than people just shouting about exploits they
> have created.
Sounds true.
> In this specific case, from leaked vendor-sec conversations, even
> Linus was not convinced that the bug was anything but a denial of
> service inherent in the Linux kernel design until after it leaked
> and someone made a local root exploit out of it. We can assume that
> Linus was not being dishonest or malicious but instead just didn't
> spot the potential implications until later on.
Yes. A stronger position for the community would be desirable.
>> This point will have been made time and again, could or should a protocol
>> be
>> made law? If a vulnerability has taken a team of top security experts to
>> discover then the likelihood of an individual or organisation finding the
>> same vulnerability in the same amount of time must be slight in general.
>
> No, in my opinion the procedure of reporting security bugs should
> not be codified in law, since (a) the threat of full disclosure is
> required to force some vendors into action, and (b) there are plenty
> of places in the world without laws so why make the life of
> legitimate law-abiding white hats that much harder.
A voluntary procedure must be a better option, but rather than threatening a
vendor into action drawing attention to the benefits of smoother
vulnerability resolution in the long term would perhaps be more sustainable
and economical.
I've recently created an Interlinux Blog where I'll compile findings and
follow through as and when,
http://interlinux.co.uk/wordpress/
Damian
--
WWW
http://www.diaser.org.uk - Open Source Data Vault Application - beta-1
RSS
http://sourceforge.net/export/rss2_projnews.php?group_id=258272
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
