This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Requesting CVEs for glibc security issues

On 05/19/2014 09:46 AM, Will Newton wrote:
On 17 May 2014 00:55, Joseph S. Myers <> 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 security-lated states.

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

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 this information?

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]