|
Message-ID: <54CB4C7A.2070009@redhat.com> 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.