Problematic assignments for subpar reports via CVE request form

[Carsten Eiram <che@riskbasedsecurity.com>]

As most of you dealing with CVEs on a daily basis likely have noticed, a vulnerability reporter named Lin Wang of The Institute of Advanced Computing Technology, School of Computer Science and Engineering, Beihang University, Beijing, China has since July 2017 been fuzzing various programs on the Windows platform. His findings have resulted in many subpar reports. He's currently at 331 reports and there’s seemingly no end in sight.

Unfortunately, the quality of these reports is quite low. Just a few observations:

1) He does not appear to understand his findings, mostly relying on !exploitable and incorrectly claims code execution in many cases, where nothing in the crash output supports this.

2) Everything is reported as a "Buffer Overflow", because if something crashes, it must be a buffer overflow...

3) Many of the reported issues are benign crashes in client programs like Irfanview. Most researchers and vendors in our industry do not consider such issues more than stability bugs. Historically, they have also very rarely been assigned CVEs (yet these for some reason do get them).

4) Many reported issues are very likely duplicates, as the vulnerability reporter basically treats every single unique crash location as a distinct vulnerability without doing any follow-up analysis.

All this is only a problem since he appears to be using the MITRE CVE request form to obtain CVEs seemingly without any real vetting of the reports.

Two problematic examples from the recent batch:

"

======================================================

Name: CVE-2017-15790

Status: Candidate

URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15790

Final-Decision:

Interim-Decision:

Modified:

Proposed:

Assigned: 20171022

Category:

Reference: MISC:https://github.com/wlinzi/security_advisories/tree/master/CVE-2017-15790

IrfanView version 4.50 (64bit) allows attackers to cause a denial of

service or possibly have unspecified other impact via a crafted .dll

file that is mishandled during an attempt to render the DLL icon,

related to a "Read Access Violation starting at

ntdll!LdrpResCompareResourceNames+0x0000000000000120."

======================================================

Name: CVE-2017-15791

Status: Candidate

URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15791

Final-Decision:

Interim-Decision:

Modified:

Proposed:

Assigned: 20171022

Category:

Reference: MISC:https://github.com/wlinzi/security_advisories/tree/master/CVE-2017-15791

IrfanView version 4.50 (64bit) allows attackers to cause a denial of

service or possibly have unspecified other impact via a crafted .dll

file that is mishandled during an attempt to render the DLL icon,

related to "Data from Faulting Address controls Branch Selection

starting at ntdll!LdrpResCompareResourceNames+0x00000000000000de."

"

Both of these crashes occur pretty close to each other within ntdll.dll, though the root cause is highly unlikely to be found here. Instead, the cause may be some type of heap corruption within a component of IrfanView itself. In cases of memory corruption, we know crashes may manifest in different ways and even in completely different components. Automatically treating each crash as a unique vulnerability and thus assigning individual CVEs is problematic. Among many other issues it may grossly inflate the number of issues thought to impact these programs.

If we look at the stack traces for these two CVEs, they're pretty much identical. This further supports they're very likely due to the same root cause, though we can't say for certain without testing. Odds are in that favour, though.

If only it was possible for third-parties including MITRE to validate these reports. Regretfully, the vulnerability reporter seemingly refuses to provide his PoCs together with the reports to allow such third-party analysis to confirm the reports’ validity.

One CVE board member, Brian Martin, reached out to the vulnerability reporter a few months ago by creating a new issue in his Github repository, where the advisories are posted. Brian politely explained the reports are problematic and asked for PoCs to be included. The issue was just closed with a short "Thank you for your suggestion" (paraphrasing since the issue seems to have been removed).

So far there have been no improvements to the reports, and no PoCs are being provided. After this request, the researcher also blocked creation of new issues in his repository, preventing third-parties from commenting on the reports and suggesting improvements. Clearly he has indicated that he has no interest in feedback on his reports.

As I've discussed in a previous email on a different matter, I think it's important for CVE to have a "you have to be this tall to ride the ride" bar. We should encourage researchers to create reports that have a minimum level of quality and reliability in order to obtain CVEs. If CVEs are haphazardly assigned for non-issues and duplicates, the value of CVE not only diminishes greatly, but we enable people to create subpar reports and just focus on getting as many CVEs as possible without doing their due diligence. We want the standard for vulnerability reporting to be higher in our industry; not lower.

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.

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.

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.

/Carsten