RE: clarification / statement on recent CVE abstraction policy changes and more

["Coffin, Chris" <ccoffin@mitre.org>]

Brian,

All of the changes you have noted result from recent changes to the CVE 
program. Most of these issues come down to changes implemented as part 
of the new CNA Rules that took effect in October 2016. All of these 
changes were previously discussed with the CVE Board. Also note that 
these examples include a description that was written by the requester 
and submitted via the CVE web form. Using requester-provided 
descriptions is one part of our overall strategy to scale the CVE 
program.

> The first issue is just odd, and seems like someone was in a hurry, 
> but this is problematic to sites using CVE data to generate stats, as 
> the product names potentially don't match prior entries

While these examples are generally not the norm, MITRE has not 
attempted to normalize product names. We have always expected those who 
build on the CVE data, like NVD, to provide this type of value add. 
However, this may be a good topic for a future Board meeting.

> I also noticed that whoever made these recent entries didn't include 
> the obvious fixing commits that were referenced in the bug tickets. 

MITRE's policy does not require including the fixing commits, even 
though we have done so in previous cases. Also, if another reference 
can be easily found via one already included then we may skip the 
former.

> The use of arbitrary date-based "versions" that are not in line with 
> the vendor versions.

As far as we can tell, this is an isolated case in which the product is 
not versioned.  The requester chose to include the date of the fix, 
which we considered reasonable. 

> We usually see this with low-end researchers trying to pass off 
> site-specific issues as products and using a date as the version 
> (e.g. 
> CVE-2017-6479)

We rarely see dates as versions, and when we do, it is usually because 
the vendor has chosen to use the date as a version (e.g. 
CVE-2016-7511).  There is no question whether CVE-2017-6479 is 
site-specific because the reference the requester provided clearly 
links to a git repository where the code can be downloaded.

> An apparent change in abstraction rule where five IDs were assigned 
> for XSS issues that previously would have received one ID (e.g.
> CVE-2017-6487, CVE-2017-6488, CVE-2017-6489, CVE-2017-6490, and
> CVE-2017-6491)

In this case the requester provided separate reports that appeared to 
be independently fixable. The change to split by independently fixable 
vulnerabilities rather than vulnerability type was enacted with the new 
CNA Rules.


The CVE Team


-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
jericho
Sent: Sunday, March 05, 2017 6:42 PM
To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: clarification / statement on recent CVE abstraction policy 
changes and more
Importance: High

MITRE,

Could you please give the board an update about recent changes in CVE 
entries? Three things jumped out on the latest batch:

1. The lack of a proper product name (e.g. CVE-2017-6478, CVE-2017-6479,
    CVE-2017-6480)
2. The use of arbitrary date-based "versions" that are not in line with
    the vendor versions. We usually see this with low-end researchers
    trying to pass off site-specific issues as products and using a 
date as
    the version (e.g. CVE-2017-6479)
3. An apparent change in abstraction rule where five IDs were assigned
    for XSS issues that previously would have received one ID (e.g.
    CVE-2017-6487, CVE-2017-6488, CVE-2017-6489, CVE-2017-6490, and
    CVE-2017-6491). It appears the only reason you abstracted is that
    different bug tracker tickets were opened, despite the same version
    being impacted, same researcher, same date, etc.

The first issue is just odd, and seems like someone was in a hurry, but 
this is problematic to sites using CVE data to generate stats, as the 
product names potentially don't match prior entries. I also noticed 
that whoever made these recent entries didn't include the obvious 
fixing commits that were referenced in the bug tickets. Basically, just 
sloppy work.

The second one is very concerning, because yeah. I shouldn't have to 
elaborate on that one.

The third one just seems to break a long-standing abstraction policy. I 
have a feeling the "different tickets" will be the justification as 
mentioned above, but also fairly certain that multiple mail list posts 
(e.g. Bugtraq or Full-Disclosure) from the same person on the same date 
affecting the same version of the same product didn't warrant splits 
before.

Any clarity on policy changes regarding these issues would be 
appreciated.

.b