RE: Regarding CVE assignments on oss-sec mailing list

["Evans, Jonathan L." <jevans@mitre.org>]

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

> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-
> board-list@lists.mitre.org] On Behalf Of Mark J Cox
> Sent: Tuesday, December 08, 2015 5:58 AM
> To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
> Subject: Re: Regarding CVE assignments on oss-sec mailing list
>
> > "Just as a reminder, there's currently no agreement in place between
> > the MITRE CVE team and Red Hat that would let Red Hat assign a CVE ID
> > for a public report in this way."
>
> I spotted a security advisory come out from my team today which had no CVE
> on it.  What, how is that possible?  We make a big deal about having
> vulnerability identifiers on every vulnerability we fix in a Red Hat
> security advisory, since we started doing this 15-odd years ago.
>
> https://rhn.redhat.com/errata/RHSA-2015-2515.html
>
> My team told me we'd fixed the same issue already in November in different
> products.
>
> A request for a CVE name went to oss-security in October, and repinged in
> November just before the first advisory.
>
> http://seclists.org/oss-sec/2015/q4/358
>
> In the past we'd simply just take something our of CNA and ask for
> forgiveness later, kind of like Kurt did for the issue in this thread.
>
> I figure a security issue being fixed in Red Hat Enterprise Linux is
> something that's going to get a CVE, no matter what reduced inclusion
> criteria may apply (it's not even in an obscure component or some older
> version, this is the latest RHEL and git)
>
> We want to have a vulnerability identifier for every vulnerabilty we know
> we're fixing.  So that means we either keep pinging and calling
> people at Mitre before any similar RHSA, or start to abuse our CNA powers,
> or invent our own temporary CXX prefix for these.
>
> Mark