Qualcom (and other) Android CVE IDs

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Qualcom (and other) Android CVE IDs

Art Manion
Good to see CVE used to identify vulnerabilities:

  https://source.android.com/security/bulletin/2017-06-01#qualcomm-closed-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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

kseifried@redhat.com
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-closed-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: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Qualcom (and other) Android CVE IDs

Beverly Finch
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
[hidden email]



Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums







-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, June 6, 2017 11:13 AM
To: Art Manion; [hidden email]
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: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

kseifried@redhat.com
One comment: are we going to make IMPACT a required field at some point? I'm wondering if CVEs such as:


are worth having? There's no mention of the CVE in the github repo for the software:


There's nothing much in the Apple release notes:


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 <[hidden email]> 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

<a href="tel:%2B1%20919%20294%205873" value="+19192945873">+1 919 294 5873
[hidden email]



Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums







-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, June 6, 2017 11:13 AM
To: Art Manion; [hidden email]
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: [hidden email]



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Adinolfi, Daniel R
In reply to this post by Beverly Finch

Folks,

 

The CNA Coordinator (hi!) is responsible for working with CNAs and improving their performance within CVE, and I do regularly reach out to CNAs when there are problems or questions regarding their submissions or lack thereof. (Our Content Team also regularly pushes back on submissions that look off when they are submitted, but it is difficult to know when CVE IDs are made public if our team isn't notified directly or when a CVE IDs is assigned and never made public.)

 

Capturing what we can in the metrics and sharing those with the Board and with the CNAs will help, and we continue to work on automation techniques and documentation to help get CNAs into the habit of notifying us as they go public with their assignments. As we iterate over the process in the future, we should be able to weed out CNAs that repeatedly make assignments that never go public or make assignments that are public but are never shared with the CVE Team or not well described.

 

-Dan

 

 

From: <[hidden email]> on behalf of Beverly Finch <[hidden email]>
Date: Tuesday, June 6, 2017 at 14:53
To: "[hidden email]" <[hidden email]>, Art Manion <[hidden email]>, cve-editorial-board-list <[hidden email]>
Subject: RE: Qualcom (and other) Android CVE IDs

 

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

 

 

 

Lenovo.com 

Twitter | Facebook | Instagram | Blogs | Forums

 

 

 

 

 

 

 

-----Original Message-----

Sent: Tuesday, June 6, 2017 11:13 AM

To: Art Manion; [hidden email]

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:

  

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:

 

 

With some interesting notes like:

 

 

=======

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:

 

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: [hidden email]

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Qualcom (and other) Android CVE IDs

Beverly Finch

Hi!!!  I figured this was the process and all the more reason for the metrics reporting going back to the CNAs.  After a few report cycles, you might add a ‘wall of shame’ slide at the end (provided we are not on it, of course).  J

 

 

 

Regards,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Adinolfi, Daniel R
Sent: Wednesday, June 7, 2017 9:25 AM
To: cve-editorial-board-list
Subject: Re: Qualcom (and other) Android CVE IDs

 

Folks,

 

The CNA Coordinator (hi!) is responsible for working with CNAs and improving their performance within CVE, and I do regularly reach out to CNAs when there are problems or questions regarding their submissions or lack thereof. (Our Content Team also regularly pushes back on submissions that look off when they are submitted, but it is difficult to know when CVE IDs are made public if our team isn't notified directly or when a CVE IDs is assigned and never made public.)

 

Capturing what we can in the metrics and sharing those with the Board and with the CNAs will help, and we continue to work on automation techniques and documentation to help get CNAs into the habit of notifying us as they go public with their assignments. As we iterate over the process in the future, we should be able to weed out CNAs that repeatedly make assignments that never go public or make assignments that are public but are never shared with the CVE Team or not well described.

 

-Dan

 

 

From: <[hidden email]> on behalf of Beverly Finch <[hidden email]>
Date: Tuesday, June 6, 2017 at 14:53
To: "[hidden email]" <[hidden email]>, Art Manion <[hidden email]>, cve-editorial-board-list <[hidden email]>
Subject: RE: Qualcom (and other) Android CVE IDs

 

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

 

 

 

Lenovo.com 

Twitter | Facebook | Instagram | Blogs | Forums

 

 

 

 

 

 

 

-----Original Message-----

Sent: Tuesday, June 6, 2017 11:13 AM

To: Art Manion; [hidden email]

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:

  

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:

 

 

With some interesting notes like:

 

 

=======

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:

 

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: [hidden email]

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

kseifried@redhat.com
Shame most likely will not work (I suspect it's due to the intersection
of large patches that you either apply, or not, and the fact that as a
consumer of such systems, you simply can't *not* apply the patches, so
the patch notes/cve descriptions/etc don't really matter that much).
When you can pick and choose which CVEs you're dealing with it makes
more sense to demand quality CVEs from your vendor, and when you have to
coordinate it makes more sense that you'll have quality CVEs (as you
have to share details anyways).

On 06/07/2017 07:57 AM, Beverly Finch wrote:

> Hi!!!  I figured this was the process and all the more reason for the
> metrics reporting going back to the CNAs.  After a few report cycles,
> you might add a ‘wall of shame’ slide at the end (provided we are not on
> it, of course).  J
>
>  
>
>  
>
>  
>
> Regards,
>
>  
>
> http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif
>
> *Beverly M Finch, PMP*
> PSIRT Program Manager
>
> Product Security Office
>
> 7001 Development Drive
>
> Office 3N-C1
>
> Morrisville, NC  27560
>
>
>
> Phone+1 919 294 5873
> [hidden email] <mailto:[hidden email]>
>
>
>
> Lenovo.com  <http://www.lenovo.com/>
> Twitter <http://twitter.com/lenovo> | Facebook
> <http://www.facebook.com/lenovo> | Instagram
> <https://instagram.com/lenovo> | Blogs
> <http://blog.lenovo.com/> | Forums <http://forums.lenovo.com/>
>
>
>
> DifferentBetter-Pink
>
>
>
>  
>
>  
>
> *From:*[hidden email]
> [mailto:[hidden email]] *On Behalf Of
> *Adinolfi, Daniel R
> *Sent:* Wednesday, June 7, 2017 9:25 AM
> *To:* cve-editorial-board-list
> *Subject:* Re: Qualcom (and other) Android CVE IDs
>
>  
>
> Folks,
>
>  
>
> The CNA Coordinator (hi!) is responsible for working with CNAs and
> improving their performance within CVE, and I do regularly reach out to
> CNAs when there are problems or questions regarding their submissions or
> lack thereof. (Our Content Team also regularly pushes back on
> submissions that look off when they are submitted, but it is difficult
> to know when CVE IDs are made public if our team isn't notified directly
> or when a CVE IDs is assigned and never made public.)
>
>  
>
> Capturing what we can in the metrics and sharing those with the Board
> and with the CNAs will help, and we continue to work on automation
> techniques and documentation to help get CNAs into the habit of
> notifying us as they go public with their assignments. As we iterate
> over the process in the future, we should be able to weed out CNAs that
> repeatedly make assignments that never go public or make assignments
> that are public but are never shared with the CVE Team or not well
> described.
>
>  
>
> -Dan
>
>  
>
>  
>
> *From: *<[hidden email]
> <mailto:[hidden email]>> on behalf of
> Beverly Finch <[hidden email] <mailto:[hidden email]>>
> *Date: *Tuesday, June 6, 2017 at 14:53
> *To: *"[hidden email] <mailto:[hidden email]>"
> <[hidden email] <mailto:[hidden email]>>, Art Manion
> <[hidden email] <mailto:[hidden email]>>, cve-editorial-board-list
> <[hidden email]
> <mailto:[hidden email]>>
> *Subject: *RE: Qualcom (and other) Android CVE IDs
>
>  
>
> 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
>
> [hidden email] <mailto:[hidden email]>
>
>  
>
>  
>
>  
>
> Lenovo.com
>
> Twitter | Facebook | Instagram | Blogs | Forums
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> -----Original Message-----
>
> From: [hidden email]
> <mailto:[hidden email]>
> [mailto:[hidden email]] On Behalf Of
> [hidden email] <mailto:[hidden email]>
>
> Sent: Tuesday, June 6, 2017 11:13 AM
>
> To: Art Manion; [hidden email]
> <mailto:[hidden email]>
>
> 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:
> [hidden email] <mailto:[hidden email]>
>
>  
>

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Pascal Meunier
In reply to this post by kseifried@redhat.com
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 <[hidden email]>
> 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
> > [hidden email]
> >
> >
> >
> > Lenovo.com
> > Twitter | Facebook | Instagram | Blogs | Forums
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:
> > [hidden email]] On Behalf Of
> > [hidden email]
> > Sent: Tuesday, June 6, 2017 11:13 AM
> > To: Art Manion; [hidden email]
> > 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:
> > [hidden email]
> >
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Pascal Meunier
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 <[hidden email]> 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 <[hidden email]>
> >> 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
> >>> [hidden email]
> >>>
> >>>
> >>>
> >>> Lenovo.com
> >>> Twitter | Facebook | Instagram | Blogs | Forums
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [hidden email] [mailto:
> >>> [hidden email]] On Behalf Of
> >>> [hidden email]
> >>> Sent: Tuesday, June 6, 2017 11:13 AM
> >>> To: Art Manion; [hidden email]
> >>> 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:
> >>> [hidden email]
> >>>
> >>
> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Art Manion
On 2017-06-14 16:08, Pascal Meunier wrote:

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

Or name a function even, if that's an appropriate level of abstraction at which to differentiate.

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

Agree.  Identification (and sufficient de-duplication) is the main goal, technical impact is (strongly?) preferred but optional.

 - Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Pascal Meunier
On Wed, 2017-06-14 at 16:40 -0400, Art Manion wrote:
> Or name a function even, if that's an appropriate level of abstraction
> at which to differentiate.

Good idea!

Pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

jericho
In reply to this post by Pascal Meunier
Case in point from today. These two CVE do not give any indication which
ID applies to which issue reported, despite the report numbering them (1),
(2), and (3). This has been a growing problem for a couple months now,
even with open source assignments.

Name: CVE-2017-9622
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9622
Assigned: 20170614
CONFIRM:https://github.com/Telaxus/EPESI/commit/48fb5e81cd7a47d98bade092a5a72d8177621dbd
Reference: CONFIRM:https://github.com/Telaxus/EPESI/issues/186

Multiple cross-site scripting (XSS) vulnerabilities in Telaxus/EPESI
1.8.2 and earlier allow remote attackers to inject arbitrary web script
or HTML via crafted common data.


======================================================
Name: CVE-2017-9623
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9623
Assigned: 20170614
CONFIRM:https://github.com/Telaxus/EPESI/commit/48fb5e81cd7a47d98bade092a5a72d8177621dbd
Reference: CONFIRM:https://github.com/Telaxus/EPESI/issues/186

Multiple cross-site scripting (XSS) vulnerabilities in Telaxus/EPESI
1.8.2 and earlier allow remote attackers to inject arbitrary web script
or HTML via crafted country data.

Brian


On Wed, 14 Jun 2017, Pascal Meunier 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 <[hidden email]>
: > 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
: > > [hidden email]
: > >
: > >
: > >
: > > Lenovo.com
: > > Twitter | Facebook | Instagram | Blogs | Forums
: > >
: > >
: > >
: > >
: > >
: > >
: > >
: > > -----Original Message-----
: > > From: [hidden email] [mailto:
: > > [hidden email]] On Behalf Of
: > > [hidden email]
: > > Sent: Tuesday, June 6, 2017 11:13 AM
: > > To: Art Manion; [hidden email]
: > > 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:
: > > [hidden email]
: > >
: >
: >
: >
:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Qualcom (and other) Android CVE IDs

Pascal Meunier
In reply to this post by Art Manion
Let me refine my statements.  It makes sense for a particular CNA to
require that a random researcher specify an impact, to validate that the
report is about a real issue.  However, it also makes sense for an
authoritative source to create a well-identified entry without an impact
being specified.  An example of an authoritative source would be a CNA
creating an entry about their own product.  The impact can be specified
elsewhere, e.g., in advisories, or although not ideal, not at all.  That
last case is a problem for scoring vulnerabilities in databases and for
vulnerability management, but it's out of the scope of the CVE.

I fear that requiring impact for all CVE entries might dissuade CNAs or
researchers from making the effort of having more or better
identification factors, or that it might result in fewer useful entries.
It should be possible to decouple validation and identification goals.

Pascal

On Wed, 2017-06-14 at 16:40 -0400, Art Manion wrote:

> On 2017-06-14 16:08, Pascal Meunier wrote:
>
> > 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.
>
> Or name a function even, if that's an appropriate level of abstraction at which to differentiate.
>
> > 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.
>
> Agree.  Identification (and sufficient de-duplication) is the main goal, technical impact is (strongly?) preferred but optional.
>
>  - Art
>
Loading...