Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 May 2014 16:23:05 -0400 (EDT)
Subject: Re: CVE Request: OpenSSL NULL pointer dereference in do_ssl3_write

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:

> 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 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 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 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 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, overlaps 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.