Re: Regarding CVE assignments on oss-sec mailing list

[Kurt Seifried <kseifried@redhat.com>]

On Wed, Dec 9, 2015 at 9:37 AM, Evans, Jonathan L. <jevans@mitre.org> wrote:

Mark,

We have been actively working with the upstream vendor to determine the appropriate number of CVEs for the vulnerabilities in git.  There was no oss-security post from MITRE because the context of MITRE's work was related to previous private communication from and to the upstream vendor.

The information in the initial request (http://seclists.org/oss-sec/2015/q4/37) required us to infer the vulnerabilities from code diffs and vague changelog statements.  Historically, basing CVE assignments on this type of information has proven difficult and error prone. For example, we are not certain if Kurt's assignment of CVE-2015-7545 to "Some protocols (like git-remote-ext) can execute arbitrary code found in the URL" is correct.  The vendor may not officially support the "blindly enable recursive fetch" scenario, i.e. the user is expected to accept the risk of executing a recursive fetch from an untrusted source, and the change should be considered a security hardening feature for the convenience of their users.  MITRE relies on the vendor guidance in these situations.

In the future, we plan to respond quickly to requests like the initial one, asking the requester for the appropriate information needed to assign a CVE ID.  If the Editorial Board members have suggestions on better ways to handle these situations, we would appreciate you input.

--
Jonathan Evans
The CVE Team
The MITRE Corporation
    

When I get wonky CVE requests/security reports I usually ask for more information, which obviously is a lot easier with open source (please send me a link to the code changes/can you explain what this source code is doing exactly/etc.). For some requests (like a fuzzer) I simply push back and require valid, minimized test cases with explanations (in one case someone sent ~100 cases to distros, then after asked for clarification came back and said none were exploitable beyond a local crash in a command line file conversion app, so not CVE worthy). I generally aim for 1 business day for reply and ideally for the actual CVE assignment, a big component of this is closing the latency loop, especially as memory decays in people to quickly (ask me about something a week from now and I'll have to spend some time re-acquiring the context). 

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