RE: Problematic assignments for subpar reports via CVE request form

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

Carsten,

 

In answer specifically to the CVE IDs assigned by the MITRE CNA for Lin Wang, the rationale for a CVE ID assignment often depends on non-public information. It could be, but isn't always, a non-public PoC. There have also been cases where we have requested that Lin provide justification for his vulnerabilities. In each case he has provided the justification required. Whether or not Lin makes this additional information public would be up to him. Maybe we can nudge Lin to provide more of this information (including PoCs) in the future once the vulnerability has been fixed by the vendor.

 

The CVE team has been able to pick out the following list of separate issues and questions in this thread. It might help if we separate and discuss them individually.

1. Should we ban requesters when they have repeatedly provided questionable vulnerability details when requesting a CVE ID?
   1. MITRE will work with the Board to decide on a path forward here. One concern here is that banning a requester completely might send a negative message to the community in general and might be something we should avoid.
   2. Do other Board members feel that banning requesters is ever appropriate, or should we just put more pressure on them to justify their work when these cases crop up?
2. How should we handle researchers like Lin Wang in the future?
   1. A better path forward might be to do as suggested and flag the requester for use in future requests. Maybe we could develop some simple process for CNAs around what additional information or details might be requested in these cases. If the requester is flagged, a CNA such as MITRE could treat the request slightly different and request additional information such as a PoC. This would likely cause extra work on the part of the CNA, but the assumption is that this case would not be the norm and wouldn’t happen often. In addition to the process, we’d have to define the parameters for when to flag a requester, and what would be required from them to get the flag removed.
   2. Do other folks have suggestions for what might be required of the requester in these cases?
3. MITRE's inclusion criteria for what is a vulnerability.
   1. MITRE currently uses CNT2.2A as part of the criterion to decide if something is a vulnerability.  When the rule was proposed, there was discussion around issues such as this where a researcher was claiming a vulnerability that might be received as questionable by others. The consensus was that these assignments would be acceptable so long as remediation steps were available to dispute and reject.  If the Board no longer feels CNT2.2A is a valid criteria for deciding if something is a vulnerability, then a discussion may be needed in regards to using only CNT2.2B.
4. The community does not seem incentivized to dispute CVE assignments
   1. As mentioned above, the use of CNT2.2A seemed acceptable so long as the dispute/reject processes worked.  However, as Carsten demonstrates, those who do the research that could be used to dispute or reject a CVE aren't incentivized to provide that information to CVE. Does this change how Board members feel about CNT2.2A?
5. Preventing duplicates
   1. The comments about duplicates largely relate to some deficits that existed in CNT1 (Independently fixable). In particular, CNT1 did not provide guidance on how to handle situations where there is some evidence that two issues are the same vulnerability, but you are not certain. MITRE's policy in these cases was to follow the groupings the requester used when making the request. However, in the most recent rules revision, we proposed a change to CNT1 in which the issues would be merged into a single CVE ID if there is uncertainty on whether they are duplicates.  The change was approved and MITRE will be following it going forward.  The new rules should stop these types of possibly duplicate assignments from being made in the future. This issue partially explains why CVE-2017-15773 and CVE-2017-15738 are separate.
6. How much certainty is required before making a decision on assigning a CVE ID?
   1. Taking a step back, much of this discussion circles around the degree of certainty needed to assign a CVE ID. How is this certainty obtained and what is the cost of obtaining the certainty? Is it worth the results?
   2. Carsten: What process did you use to determine that CVE-2017-15738 and CVE-2017-15773 were duplicates? How long did it take?

 

 

Regards,

 

 

Chris and the CVE Team

 

From: Carsten Eiram [mailto:che@riskbasedsecurity.com]
Sent: Wednesday, October 25, 2017 12:56 AM
To: Coffin, Chris <ccoffin@mitre.org>
Cc: Art Manion <amanion@cert.org>; cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Problematic assignments for subpar reports via CVE request form

 

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