[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Jan 2015 10:18:50 +0100
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)
On 01/29/2015 05:00 PM, Paul Pluzhnikov wrote:
> On Thu, Jan 29, 2015 at 4:09 AM, Hanno Böck <hanno@...eck.de> wrote:
>
>> And yes: I'd like people to cry alarm every time they see a buffer
>> overflow in glibc or any other core lib.
>
> What is the appropriate forum to cry alarm on?
It depends on whether you want to do it publicly. For the public case,
you can post either on libc-alpha or here, with an appropriate subject,
and people will pick it up.
As described here,
<https://sourceware.org/glibc/wiki/Security%20Process>
glibc relies on downstreams for confidential security bug handling, so
that's another option.
The eventual goal is to flag all security bugs as security+ in the glibc
Bugzilla, but we are not quite there yet. Both historic bugs still
await analysis, and there are some remaining tough calls. The next step
after that work is complete will be to track down already-assigned CVEs
and deal with the remaining missing ones. To my knowledge, there are no
major issues among those, but it is always difficult to predict what
applications do with such a low-level library.
Apparently, we also have historic security-relevant commits without
corresponding Bugzilla bugs. This dates back to the time before glibc
switched to a more collaborative/consensus-based development model. The
current policy is that all user-visible changes need Bugzilla bugs. I
don't know what to do about those stealth commits.
--
Florian Weimer / Red Hat Product Security
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.
