Re: CVE request? buffer overflow in CIFS in 2.6.*

[Mark J Cox <mjc () redhat com>]

> Any and all thoughts are welcome.  I've thought that a big win for CVE was
> as a "universal bug ID" for the Linux community, which was outside what we
> had originally envisioned for it.  But these kinds of dynamic,
> low-information disclosures really stress the CVE process, so I'm starting
> to question whether CVE is really a good fit.

I believe that this is a by-product of vendors moving to use the public 
oss-security list for triaging issues.

Before oss-security, vendors like Red Hat would discuss vulnerabilies both 
public and private on the private vendor-sec list.  At the end of the 
discussion and peer review we'd reach some conclusion about if the issue 
was actually a security issue, and one of the Candidate Naming Authorities 
would allocate CVE names accordingly.

So usually CVE names would only get allocated for things that at least one 
of the vendors was going to fix, and therefore the CVEs had a high level 
of confidence, and lots of metadata.

For example if Red Hat fix an issue in any of our products we've got a 
public bug with the CVE name as alias which contains the details, link to 
first public mention, and a link to the fix or the fix itself (either the 
upstream one or a backported one). For issues where it was likely that 
Mitre would allocate a name by themselves (say a new version of PHP got 
released with security issues mentioned in the announcement) we'd ping 
Steve directly for a name to try to avoid duplicates (and in these cases 
Steve and his team would need to do more work).

However, for issues already public, using a closed list was not optimal, 
and so to aid peer review outside of the vendor security teams and for 
transparancy we started using oss-security.

But what happens now is that all the triage work that was previously 
hidden is now public.  So while on vendor-sec we might have used a CVE 
name for tracking an issue through triage and later rejected it with no 
public mentions, now it's public in the interim.

In the case of the Linux kernel bug Eugene was working on, that triage 
also includes the CVE Content Decisions to map vulnerabilities to CVE 
names where there were multiple similar vulnerabilities or multiple 
affected products at the same time.  If this were vendor-sec, one of the 
CNA experts would have stepped in at that point.

I don't think intermediate ids would help, and we're years past having a 
lower-confidence CVE 'candidate' (CAN).

So perhaps the solution is to have the vendor CNAs play more of a role on 
the oss-security list in allocating and helping with content decisions 
rather than having to have Mitre monitor the list.  Then, each time a CNA 
gives out a CVE on oss-security they could have some requirement of a 
mimimum set of information about the allocation they have to provide in 
the same mail.  By having the CNA buffer we'd only have to involve Steve 
or Mitre when something is complex.  However, that would mean Mitre would 
have to check oss-security list before allocating any CVE names for 
oss-issues and accept there may be more duplicate allocations.

Thanks, Mark
--
Mark J Cox / Director, Red Hat Security Response