Requesting CVEs for glibc security issues

[Florian Weimer]

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