This is the mail archive of the
mailing list for the glibc project.
Re: Requesting CVEs for glibc security issues
- From: Florian Weimer <fweimer at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Jeff Law <law at redhat dot com>, OndÅej BÃlka <neleai at seznam dot cz>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 10 Jun 2014 18:59:51 +0200
- Subject: Re: Requesting CVEs for glibc security issues
- Authentication-results: sourceware.org; auth=none
- References: <CANu=DmjYiCT8NRbtdrXXrJtK_-mGRmsN+KUV50oEzaGY7tqn0Q at mail dot gmail dot com>
On 05/19/2014 09:46 AM, Will Newton wrote:
On 17 May 2014 00:55, Joseph S. Myers <email@example.com> wrote:
On Fri, 16 May 2014, Jeff Law wrote:
E.g. bug 16618 (something I'd have
thought would be a natural case for a CVE - wscanf may not be widely used,
but it's still a buffer overrun if wscanf is used -
More likely nobody's contacted the appropriate folks. Sounds like it'd be
worth of a CVE to me.
I'm sort of presuming that some distribution security people are watching
for newly filed glibc bugs that seem CVE-worthy, and requesting CVEs.
I don't think this is happening right now. As others, I've been doing
this from time to time, but it hasn't happened in a consistent fashion.
This doesn't seem to be the case. I am not sure of the
political/economic motivations behind creating CVEs but it seems the
onus is on the bug reporter/fixer to request a CVE on the oss-security
list. In my opinion it would be useful if the glibc project had some
kind of security person or team which could make sure any security
bugs are identified and CVEs requested.
Would it be possible to add a tristate security flag to Bugzilla, with
states "security bug", "not a security bug", "don't know/not yet
triaged" (obviously with better/shorter names)? This would have be
searchable, so that it's possible to list all bugs in particular
I would like to volunteer to classify new bugs as needed, and in the
longer term, go back and revisit all the old bugs.
CVE assignment would then indirectly and eventually fall out of our
regular upstream monitoring, which triggers on new or re-classified
For embargoed issues, we should just list a couple of downstreams who
have experience dealing with embargoes, and tell the submitter to pick
their favorite one. This is what happens right now, and it seems to
work fairly well, apart from the usual pain associated with embargoes.
(We should use them only for really critical issues, such as likely code
execution over the network, or demonstrable local privilege escalation.
Reports can file private reports with downstreams, but I expect them
to push for publication.) Do we already have a Wiki page which details
It would also be useful to do the backports to stable branches of the
security fix, but at the moment it seems every vendor has their own
Right, there's no real global synchronization there, and some of us face
â challenges when it comes to doing sustaining engineering upstream anyway.
Florian Weimer / Red Hat Product Security Team