Re: Qualcom (and other) Android CVE IDs

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

Identification is our mission;  source code commits are awesome for that
and in that case I'd suggest saying "but in (a) different (part of the)
code than CVE-... (commit links forthcoming)".  That would be
exceptionally good. 

I believe impact isn't necessary for identification, although it can
help.  Sometimes the impact can be up to someone with enough imagination
to get something else to happen.  So if we rely on impact as the only
thing differentiating a CVE from another, or a crucial (required)
identification factor, then the CVE entries could be on shifting
grounds.

Pascal

On Wed, 2017-06-14 at 13:21 -0600, Kurt Seifried wrote:
> So I actually just finished writing two with that phrase, they have
> details but are also semi related (and obviously once public and
> source code commits are linked to it becomes more obvious). I just
> worry that if we set the bar to low do we allow cve compliance to
> consist of "no details, unknown avenue of exploitation, unknown
> impact" entries?
> 
> 
> -Kurt
> 
> 
> 
> 
> 
> > On Jun 14, 2017, at 12:55, Pascal Meunier 
> > <pmeunier@cerias.purdue.edu> wrote:
> > 
> > Those entries are certainly vague and I wish they had more details, 
> > but
> > they absolutely are worth having.  I would suggest not making 
> > "Impact"
> > required.  The CVE's fundamental mission is to uniquely identify
> > vulnerabilities.  I don't like, but am willing to accept, entries 
> > that
> > are so poor in information that only some people can uniquely 
> > identify a
> > vulnerability based on it, on an optimistic basis that these people 
> > are
> > trustworthy in this regard.  Obviously this is far from the ideal 
> > case,
> > and for CVEs to be academically useful much more information is 
> > needed,
> > but it's better than nothing.  
> > 
> > What concerns me the most is that nobody could differentiate 
> > between 2
> > CVE entries.  This has happened for example when an entry contains
> > something like this in the description: "but different from 
> > CVE-...".
> > If you need to specify that, it's a strong indication that your 
> > entries
> > are much too vague right from the start.  I think there should be a
> > commitment from sources to provide enough information, or a refusal 
> > from
> > CNAs, so that this turn of phrase is never needed.
> > 
> > Pascal
> > 
> >> On Tue, 2017-06-06 at 18:34 -0600, Kurt Seifried wrote:
> >> One comment: are we going to make IMPACT a required field at some 
> >> point?
> >> I'm wondering if CVEs such as:
> >> 
> >> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=unspecified+impact+via+
> >> unknown+vectors+apple
> >> 
> >> are worth having? There's no mention of the CVE in the github repo 
> >> for the
> >> software:
> >> 
> >> https://github.com/nghttp2/nghttp2/search?utf8=%E2%9C%93&q=CVE-2017-2428&type=
> >> 
> >> There's nothing much in the Apple release notes:
> >> 
> >> https://support.apple.com/en-ca/HT207615
> >> 
> >> Impact: A malicious HTTP/2 server may be able to cause undefined 
> >> behavior
> >> 
> >> Description: Multiple issues existed in nghttp2 before 1.17.0. 
> >> These were
> >> addressed by updating nghttp2 to version 1.17.0.
> >> 
> >> 
> >> 
> >> On Tue, Jun 6, 2017 at 12:53 PM, Beverly Finch 
> >> <beverlyfinch@lenovo.com>
> >> wrote:
> >> 
> >>> I suppose one of the charts in the deck we reviewed in the past 
> >>> few weeks
> >>> addresses this problem where number of CVEs is reserved but not 
> >>> 'published.'
> >>> If Qualcomm (and others) are publishing the CVEs without 
> >>> submitting the
> >>> descriptions back to Mitre, shouldn't someone be reaching out to 
> >>> them to
> >>> 'remind' them of the process?
> >>> Or would this be a full time job for someone?
> >>> 
> >>> 
> >>> 
> >>> Regards,
> >>> 
> >>> 
> >>> Beverly M Finch, PMP
> >>> PSIRT Program Manager
> >>> Product Security Office
> >>> 
> >>> 7001 Development Drive
> >>> Office 3N-C1
> >>> Morrisville, NC  27560
> >>> 
> >>> +1 919 294 5873
> >>> beverlyfinch@lenovo.com
> >>> 
> >>> 
> >>> 
> >>> Lenovo.com
> >>> Twitter | Facebook | Instagram | Blogs | Forums
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> -----Original Message-----
> >>> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:
> >>> owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of
> >>> kseifried@redhat.com
> >>> Sent: Tuesday, June 6, 2017 11:13 AM
> >>> To: Art Manion; cve-editorial-board-list@lists.mitre.org
> >>> Subject: Re: Qualcom (and other) Android CVE IDs
> >>> 
> >>>> On 06/06/2017 08:25 AM, Art Manion wrote:
> >>>> Good to see CVE used to identify vulnerabilities:
> >>>> 
> >>>> 
> >>>> https://source.android.com/security/bulletin/2017-06-01#qualcomm-close
> >>>> d-source-components
> >>>> 
> >>>> but there's little or no information about any of these
> >>> vulnerabilities.  Lots of RESERVED.
> >>>> 
> >>>> This touches on the use of CVE for "internal" finds.  There's 
> >>>> value in
> >>> having a public label, but the lack of even summary information 
> >>> (minimal
> >>> CVE entry) is problematic.
> >>>> 
> >>>> - Art
> >>> 
> >>> Also the thread on oss-sec:
> >>> 
> >>> http://seclists.org/oss-sec/2017/q2/378
> >>> 
> >>> With some interesting notes like:
> >>> 
> >>> http://seclists.org/oss-sec/2017/q2/380
> >>> 
> >>> =======
> >>> I don't know about apple itself but in the clusterfuzz reports I 
> >>> see 4
> >>> public bugs about sqlite. However they have a very small (2 days) 
> >>> range of
> >>> regression, i.e. a commit made in those two days causes the 
> >>> problem.
> >>> I didn't check, but I suspect they didn't go in any release.
> >>> 
> >>> FTR, the time you are seeing in the regression range is UTC:
> >>> https://github.com/google/oss-fuzz/issues/563
> >>> 
> >>> At this point I don't know if apple referer to those issues or the
> >>> mentioned issues are not public.
> >>> 
> >>> --
> >>> Agostino Sarubbo
> >>> =======
> >>> 
> >>> Basically these issues have CVE's but I (nor anyone else really) 
> >>> has any
> >>> clue what is actually affected and if we need to deal with it or 
> >>> not.
> >>> Kind of defeats the point :P.
> >>> 
> >>> 
> >>> 
> >>> --
> >>> 
> >>> 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
> >>> 
> >> 
> >> 
> >> 
>