[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54CA64B9.3070901@redhat.com>
Date: Thu, 29 Jan 2015 09:50:01 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)
On 29/01/15 05:09 AM, Hanno Böck wrote:
> On Thu, 29 Jan 2015 02:05:38 -0700
> Kurt Seifried <kseifried@...hat.com> wrote:
>
>> So you'll be doing the work to confirm which ones are/are not, patch
>> them, regression test the patches and so on? Awesome!
>>
>> There's a reason we don't treat every potential security flaw as a
>> security vulnerability. We have finite resources and pretty much an
>> infinite number of flaws to deal with. Until you solve that problem we
>> have to make due with "best effort", letting perfection be the enemy
>> of good will kill us.
>
> I find that sarcastic comment inappropriate. After all it's your
> company that's selling a product that makes the promise to backport
> important security fixes for years.
Which we do... when we find out about them. That's sort of the problem
here. People are fixing security flaws, and as Michael Zalewski's post
eloquently points out, a lot of them are not treated as security bugs
for various reasons, and thus all the vendors backporting may not find
out about them. We do monitor quite a few sources but the Open Source
world is rather massive and the number of commits daily is on the large
side.
This is why for example I've been trying to make CVE's easily available
so people are more likely to come to us with borderline issues ("I'm not
sure but this looks weird and may be security related"). I'm also
working on a set of examples for the CVE HOWTO so again developers will
hopefully be able to realize when things look weird and may be a
security issue and not just a flaw. I'm trying to find ways to help
educate people/make it easier for them to report security issues but
this is a non trivial problem.
We also are willing to help people coordinate disclosure/inform
upstreams (this is quite often a more difficult task than it should be),
again to minimize the chances of things being missed and people being
impacted.
> I think we have a real problem here and I'd like to have a talk how to
> solve it. Debian, Redhat, Ubuntu and many others are making an implicit
> promise with their long time supported stable distributions that they'll
> take care of important bugs. I have big doubts how capable they are in
> delivering that promise. There are just too many bugs to take care of.
Solving it is easy. Solving it in an economic manner that doesn't cost
an obscene amount of money is another matter. This also ignores the
simple fact that even with an unlimited supply of money the number of
security skilled developers is not currently that huge. Witness the
number of people participating on this list, or finding security bugs,
or doing security research.
> I'll write up something longer on that topic later today.
>
> And yes: I'd like people to cry alarm every time they see a buffer
> overflow in glibc or any other core lib. Even if we aren't capable of
> deeply checking every one of them: Having the information available
> somewhere else than depply hidden in a google bugtracker would be an
> improvement. If it is too much for this list create another place for
> it.
Having it at least be accessible to many people (e.g. the public) would
probably be better than not I suspect. The bad guys will find out
regardless if they really want to find a vuln to exploit, at least we
can give the good guys a chance. But my concern is still "who does the
work with all these alarms to confirm if they are in fact security or
just a flaw" so we don't just end up with a huge pile of "maybe".
TL;DR: The tragedy of the commons, we're knee deep in sheep poop. Some
of it may be on fire.
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
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.
