clarification / statement on recent CVE abstraction policy changes and more

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

clarification / statement on recent CVE abstraction policy changes and more

jericho
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
Reply | Threaded
Open this post in threaded view
|

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

Coffin, Chris
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: [hidden email] [mailto:[hidden email]] On Behalf Of jericho
Sent: Sunday, March 05, 2017 6:42 PM
To: cve-editorial-board-list <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

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

jericho
On Mon, 6 Mar 2017, Coffin, Chris wrote:

: 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.

I think the CVE entry should have a way to flag it as such, so that
consumers know this was not written by MITRE and may not meet MITRE's
historical standards. That would be a simple addition to the process, a
check box essentially, and way to visually flag it.

: > 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

And yet, MITRE has done a good job normalizing products in descriptions
historically. =)

: > 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.

Policy maybe not, but given the excessively detailed replies to some
issues on oss-sec in the past, and digging into the commit to the tune of
30 minutes of coding/vuln analysis becomes quite the contrast to "didn't
link the fixing commit that was in the bug entry linked".

: > 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.

Interesting, thanks.

.b