Re: Qualcom (and other) Android CVE IDs

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

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