Re: Qualcom (and other) Android CVE IDs

["kseifried@redhat.com" <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
> Emailbeverlyfinch@lenovo.com <mailto:beverlyfinch@lenovo.com>
> 
>       
> 
> 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:*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
> <mailto:owner-cve-editorial-board-list@lists.mitre.org>> on behalf of
> Beverly Finch <beverlyfinch@lenovo.com 
> <mailto:beverlyfinch@lenovo.com>>
> *Date: *Tuesday, June 6, 2017 at 14:53
> *To: *"kseifried@redhat.com <mailto:kseifried@redhat.com>"
> <kseifried@redhat.com <mailto:kseifried@redhat.com>>, Art Manion
> <amanion@cert.org <mailto:amanion@cert.org>>, cve-editorial-board-list
> <cve-editorial-board-list@lists.mitre.org
> <mailto: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
> 
> beverlyfinch@lenovo.com <mailto: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>
> [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of
> kseifried@redhat.com <mailto:kseifried@redhat.com>
> 
> Sent: Tuesday, June 6, 2017 11:13 AM
> 
> To: Art Manion; cve-editorial-board-list@lists.mitre.org
> <mailto: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 <mailto:secalert@redhat.com>
> 
>  
> 

-- 

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