Re: Problematic assignments for subpar reports via CVE request form

[Kurt Seifried <kseifried@redhat.com>]

On Mon, Oct 23, 2017 at 10:51 AM, Art Manion <amanion@cert.org> wrote:

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.

I wouldn't say go straight to ban. My current method is basically a sliding scale, the better you are the more likely I am to give you a CVE without asking for much (e.g. Curl/Jenkins/etc.). But if you;re unknown to me I'll ask for more data, and if you're usually wrong/trolling seems apparent I'd ask for even more detail/proof. I would only go to the ban phase if they are flooding in requests that are still of poor quality despite being told they need to do better quality requests, I would suggest we adopt this, it's somewhat subjective, but relatively simple:

"your report seems incomplete, so no CVE at this time, but if you can submit more details and prove it, please do"

 

Regards,

 - Art

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com