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