RE: Problematic assignments for subpar reports via CVE request form

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

> Not to put the burden entirely on the messenger, but can't anyone (or 
> at least a CNA like RBS) DISPUTE a CVE entry?  This would be the 
> crowd-based approach, assuming some vendor CNAs don't notice or care 
> about inaccurate CVE entries.

Yes... Art is absolutely correct on this point. See the CNA Rules v1.1 
(page 22).
"Dispute: Validity of the Vulnerability is Questioned Not everyone 
shares the same definition of a vulnerability. One person’s 
vulnerability is another person’s security hardening opportunity, and 
another person’s intended functionality. How does CVE deal with these 
differing opinions?
When an authoritative source disputes the validity of the 
vulnerability, “"** DISPUTED **” is added to the beginning of the 
description, and a short NOTE is added to the end explaining why the 
vulnerability is disputed. Ideally, the disputing party provides a link 
that can be added to the CVE as a reference, and a quote that can be 
used as the explanation in the NOTE. However, neither are required."

This is also consistent with the fail fast approach that has been 
discussed many times in the past. If someone notices problems with 
assignments, we can always correct and/or dispute them after the fact.

Carsten: If you would like to move forward and formally dispute the 
referenced CVE entries, please let us know.

> We should encourage researchers to create reports that have a minimum 
> level of quality and reliability in order to obtain CVEs.

Absolutely agree and we should have this discussion here. The CVE 
program should always encourage a high degree of quality and 
reliability. The program should also have a reasonable minimum level of 
quality and reliability. However, we need to be careful about how much 
is required. It's probably reasonable to assume that some researchers 
might not bother obtaining a CVE ID if a PoC was added to the list of 
requirements. 

Additionally,  there is no guarantee that all of the information 
provided to us at the time of assignment will be published or stay the 
same when it is finally published by the requester.  Also, even if we 
were given a PoC at the time of assignment, MITRE does not check the 
validity of the PoC.

A couple of additional reasons the CVE team feels that there should be 
continued assignments for Lin's requests:
- We are attempting to move the CVE Program to a federated model where 
MITRE gets out of the business of assigning and creating CVE entries. 
If we are talking about creating more upfront analysis of CVE requests 
by the MITRE CNA, we would definitely be moving backwards from prior 
discussions. It seems the better approach would be for the community to 
speak up and dispute specific entries where they are questionable based 
on real analysis.
- There is proof that Lin is coordinating with the closed-source 
vendors, e.g., http://www.irfanview.com/main_history.htm says 
"FPX/RLE/DJVU/ANI/SVG PlugIn loading bugs fixed (thanks to Lin Wang)" 
-- even in cases where the vendor is not explicitly saying it was an 
exploitable vulnerability.
- in the small fraction of cases where Lin works on Open Source, he 
apparently is finding security problems that can be reproduced, e.g., 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14686

Regards,

Chris Coffin
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 
Art Manion
Sent: Monday, October 23, 2017 11:51 AM
To: Carsten Eiram <che@riskbasedsecurity.com>; cve-editorial-board-list 
<cve-editorial-board-list@lists.mitre.org>
Subject: Re: Problematic assignments for subpar reports via CVE request 
form

On 2017-10-23 04:13, Carsten Eiram wrote:

...
> Maybe it would be worth having a discussion on the list about what 
> this bar should be and how someone gets on the #ignore list? The CVE 
> request form has made a lot of things easier, but it also seems to be 
> the cause of a lot of problematic and invalid assignments.

Bug bounty/disclosure management platforms measure reputation and S/N 
ratio.

> I do not think it is the responsibility of MITRE and similar CNAs to 
> in-depth vet every single request. I know better than most how many 
> resources this requires. However, I do suggest some minimum level of 
> vetting is performed. Vendor CNAs are, obviously, already doing this.
> They have to in order to fix reported issues and also have no 
> interest 
> in assigning CVEs to invalid reports or duplicates, so this mostly 
> goes for CNAs like MITRE and DWF. If a report on the surface looks 
> questionable or has duplicate potential, we should be careful about 
> assigning CVEs, instead requiring the researcher requesting a CVE to 
> provide more information.

Not to put the burden entirely on the messenger, but can't anyone (or 
at least a CNA like RBS) DISPUTE a CVE entry?  This would be the 
crowd-based approach, assuming some vendor CNAs don't notice or care 
about inaccurate CVE entries.

For instance, CERT/CC raised concerns with some of these assignments:

  
<https://github.com/BastilleResearch/CableTap/tree/master/doc/advisories>

A significant concern is the effort required to refute questionable 
assignments.

One end of the spectrum is to assign liberally and wait until vendors 
DISPUTE.  Lots of cruft would build up though.  What about liberally 
accepting DISPUTE claims?  Any CNA or named vendor (reasonably 
trusted/known source) can change status to DISPUTED with a simple 
request.  Then, the alleged cruft is flagged, and burden goes on the 
Lin Wang class researcher.

> In the case of Lin Wang, without a defined minimum quality standard, 
> I 
> suggest that we for the time being stop granting him CVEs due to the 
> high rate of questionable reports. Moving forward, he should at 
> minimum provide PoCs together with his reports. That gives us an 
> opportunity to test the more questionable ones either before or after 
> CVE assignment, so we, hopefully, do not assign at all or may REJECT 
> later as needed. Furthermore, any of the crash outputs that do not 
> suggest a worse impact than a stability bug in a client application 
> should, by default, not be assigned CVEs at all.
Based on Carsten/RBS claims, I'd support a temporary ban.  But, we'll 
need to develop consistent rules/metrics (which could start as "a 
reliable CNA says you're wrong").

Also, keep in mind that the cruft and diffusion in quality and detail 
is a direct effect of choosing expansion.  Unavoidable, but still not 
something we should leave unchecked.

Regards,

 - Art