[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201405062023.s46KN5RE020277@linus.mitre.org>
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.
