Date: Tue, 6 May 2014 16:23:05 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: OpenSSL NULL pointer dereference in do_ssl3_write -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First and most importantly, we would like to confirm that MITRE will continue to use CVE-2014-0198 for the vulnerability in question, as listed at: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0198 > I think getting this one a CVE is time critical. Mitre: sorry if this > causes a duplicate, but I'm assigning a CVE now. Please use > CVE-2014-0198 for this issue. MITRE is currently responsible for assigning CVE IDs for publicly known vulnerabilities, i.e., cases where a public web site or mailing-list message mentions the existence of a vulnerability that didn't have a CVE ID assigned in advance. For a long time in the past, Red Hat had been assigning CVE IDs for publicly known vulnerabilities in open source software, especially if the vulnerability was mentioned on this list. This had been very useful to many people, but ended as of December 2013. Essentially the change was originally planned to be temporary as discussed in the http://www.openwall.com/lists/oss-security/2013/12/07/3 post but now persists. In other words, the change already happened months ago; there's no new change in May 2014, nor is any change being planned. If a vendor is on the http://cve.mitre.org/cve/cna.html list and has a vulnerability reported privately to them for software that they ship, then that vendor can assign a CVE ID. Also, CVE assignment for http://oss-security.openwall.org/wiki/mailing-lists/distros has a similar process that doesn't involve communication to or from MITRE. If an issue has a CVE request on the oss-security list, and the CVE assignment subsequently comes from outside MITRE, what this means (or, at least, SHOULD mean) is that the issue already had a privately assigned CVE ID before the public request occurred. People sending out these CVE assignments may want to mention the date of the private CVE assignment, but making the date public isn't something that MITRE requires. If there wasn't an earlier private CVE assignment, there is no option to proceed anyway because of a perception of time criticality or an expectation that an issue was "publicly known" to a smaller than usual subset of the public. There are several scenarios in which duplicate CVEs could occur if multiple parties were assigning IDs to publicly known vulnerabilities. Here are three that can be described somewhat quickly: 1. MITRE has a mostly separate team of people who populate the cve.mitre.org web site with entries about disclosures that didn't have any CVE IDs assigned in advance. While work on one of them is in progress, oss-security may get a CVE request for the same disclosure or an overlapping disclosure. Sometimes we need to let the in-progress work finish because it determines the number of CVE IDs (e.g., zero, one, or more than one). 2. Not everyone is aware of whether they publicly disclosed a vulnerability discovery. For example, if a product isn't well known and suggests that all bug reports be sent to a developers' mailing list, a researcher isn't necessarily going to know whether that list is publicly archived. 3. A public disclosure often doesn't mention all of the names under which the software has been distributed. For example, https://packages.debian.org/unstable/main/cluster-agents overlaps https://github.com/ClusterLabs/resource-agents even though the names don't have a close match. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTaUG4AAoJEKllVAevmvms3bMH/iCooibiCdjSpIqtwIW2JBx+ wHhZiGScmIs7Nop8c1X6zCzg1cT8NxNWS054hvsKygkNx3DTWtQL8RlRLUHUpLAX ID0/Bl10/CmjF3FS3DmxBUzJ6J67/M+RjAGzAu82AUzPj46cx2zmV5sEP5IfsMmW l7xA2Fzg9aGDd1701CyenJkAEDbRM2jCpV+0uFppFbofCGxbpB9JLBki+ulH40ZG 6enO0VFaX1gbg5qEboCf9UJhKkSuRxBCkaOoxelJaS466IJeQ+vUSta3HvrDzomv WGpN34cybn2aUUPZr23tx3GAqoGwmHIgNNmyQu4ESUfMo/k0EzSG4Yfj82WondQ= =mrpS -----END PGP SIGNATURE-----
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.