Re: [Hampshire] How should the Open Source world handle newv…

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"

> 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.

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.

> 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.

Black hats will do what they do regardless.

Andy

--
http://bitfolk.com/ -- No-nonsense VPS hosting

You dont have to be illiterate to use the Internet, but it help's.
-- Mike Bristow