Re: Problematic assignments for subpar reports via CVE request form

[Carsten Eiram <che@riskbasedsecurity.com>]

On Tue, Oct 24, 2017 at 12:12 AM, Coffin, Chris <ccoffin@mitre.org> wrote:

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

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.

Please note that I’m not disputing those two CVEs as invalid. There is definitely some memory corruption occurring even if the vulnerability reporter doesn’t seem to realize that. I’m suggesting they’re quite likely duplicates and making a point as to why treating unique crash locations as unique vulnerabilities is problematic. I also consider the descriptions quite poor and of little value w.r.t. covering the problem, since the issue would not be within ntdll.dll.

As for disputing the many other duplicate, incorrect, or invalid issues reported by Lin Wang, please see my email in response to Art. Additional reasons for me not disputing those is both the volume and also the fact that you later state in your response that MITRE plans to continue with these questionable assignments anyway. I see little point in cleaning up this mess just to have new issues introduced in a month or so.

I will, however, later in this email give a few examples that you may consider as official disputes and statements of duplicate assignments.

 

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

Good. I think it is very important for us to have this discussion. For the sake of clarity, I am not proposing that all researchers should provide a PoC as a requirement to obtain a CVE. I propose it specifically for Lin Wang. It would be a means for MITRE and third-parties to validate his reports, as they are questionable and lacking any proper information to determine what the problem really is - if there even is one. As we move forward, if vulnerability reporters seems unreliable or there are disputes, we should flag them and as a first step require a PoC for an assignment unless there is vendor confirmation of the issue or similar.

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.

Sure, a vulnerability reporter changing the information later is not something we can prevent. However, we can ensure CVE assignments are not given without extra vetting for questionable reports and vulnerability reporters.

  Also, even if we were given a PoC at the time of assignment, MITRE does not check the validity of the PoC.

While this may not be part of the process at MITRE, other parties - RBS included for our VulnDB solution - would be testing such PoCs and particularly for vulnerability reporters, who are considered unreliable. This would increase the chance of getting those crowd-sourced disputes.

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 a balance with a federated model and ensuring data quality that needs to be recognized. We have previously seen first hand that the "community" is not willing or technically able to sufficiently "speak up" as required.

As discussed in my original email, we can already expect vendor CNAs to do careful analysis. Vulnerability coordination / bug bounty CNAs would also be doing this, as they're not going to pay for an invalid report. Based on Kurt's response, DWF has a process as well to at least question vulnerability reporters if requests look suspect or they consider the vulnerability reporter unreliable. Those bases seem covered.

The researcher CNAs, who assign CVEs for their own findings, could be a problem, but I’d hope we can have some faith in their reports being accurate, since they’ve become a CNA. If it is later concluded that their reports are often wrong, we’d should have a process to discuss their CNA status. 

That leaves MITRE and other/future CNAs in a similar non-vendor role. Even as this moves to more of a federated model, I do not see it preventing us from defining CVE assignment criteria for such CNAs that reduce the risk of CVE assignments to questionable reports and vulnerability reporters.

 

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

We have at no point disputed that he is finding issues, but rather if the issues are in fact legitimate vulnerabilities, their severity, and risk of duplicates. However, just because one vendor thanked him for reporting something that may or may not have been a vulnerability, we shouldn’t per default assume he's generally right. Even if a CVE board member in a technical role goes on the record and says his reports are highly problematic, unreliable, and in many cases wrong, MITRE would rather disregard that and treat a vendor thank you as sufficient proof of his reports generally being correct?

- 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

Similar logic to above: Because one example shows that others could confirm his finding, he is generally right? Humoring that approach let me give two examples of where he is wrong, which should then make me doubly right that he's generally wrong.

1) CVE-2017-15773 is a duplicate assignment of CVE-2017-15738. XnView and IrfanView use the same CADImage plugin, but while IrfanView uses the latest (12.0.0.5) 64-bit version, XnView's extended edition bundles an older 32-bit version (11.1.0.3). He’s fuzzing two versions of the exact same product. For obvious reasons this causes the same bug to manifest in two different code locations and underlines why blindly treating each unique crash location as a unique vulnerability is problematic.

Furthermore, the vulnerability reporter only claims a DoS as the impact, purely speculating that it could have some other unspecified impact too. It's an OOB read where there is no immediate indication that another impact could occur. We can't rule it out (as we can't test it - no PoCs provided), but in such cases, we should consider it the responsibility of the vulnerability reporter to prove such claims. As all information provided only supports a crash due to an OOB read, this shouldn't even have been assigned a CVE in the first place. Historically, crashes in client applications like these are considered stability bugs and nothing more. Other CNAs generally don't assign for them.

Based on this example, could you please elaborate on MITRE's current policy w.r.t. assigning CVEs to issues in such client applications where there is no proof at all of a worse impact than a crash? This will help ensure consistency across the board. Did you chose to assign CVEs for such issues solely because the vulnerability reporter suggested that other unspecified impacts could occur? Does MITRE in general considers such stability bugs to be within CVE assignment scope even if most vendor CNAs and others in the industry do not?

2) CVE-2017-15777 is claimed to be a buffer overflow that allows code execution. There is no proof provided to suggest this. Instead it looks like a benign NULL pointer dereference error leading to a crash. it's even a first chance exception, so the program could potentially handle it gracefully. Disassembling the affected library and checking the crash location supports that it's likely just a NULL pointer dereference error. While we can't rule out something bad(tm) happened prior to this that caused memory corruption and overwrote memory with a NULL value, there is not a single shred of evidence for this. Again, I consider it the vulnerability reporter's responsibility to back his claims - especially when the crash output and code doesn't support it. Therefore, this is an invalid claim.

/Carsten