Date: Mon, 27 Apr 2009 10:04:20 +0100 (BST) From: Mark J Cox <mjc@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request? buffer overflow in CIFS in 2.6.* > 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
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.