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