[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Qualcom (and other) Android CVE IDs



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
Emailbeverlyfinch@lenovo.com

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

DifferentBetter-Pink

 

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] 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: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of Beverly Finch <beverlyfinch@lenovo.com>
Date: Tuesday, June 6, 2017 at 14:53
To: "kseifried@redhat.com" <kseifried@redhat.com>, Art Manion <amanion@cert.org>, cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
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

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: secalert@redhat.com

 


Page Last Updated or Reviewed: June 07, 2017