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

Re: CVE For Services



Some generic cases with examples of things that might fall in scope, or maybe not:

1) Bad HTTPS certificates/configurations (e.g. using self signed certs on the public internet, using out of date certs, certs for the wrong host name, etc.). Lots of examples of banks messing this up in Google.

2) Account/info discovery bugs in web sites, a quick set of results: https://search.theregister.co.uk/?q=account+discovery+bug&page=1&source=osd

3) Letting a domain name lapse, breaking stuff in all sorts of fun ways:  https://www.theregister.co.uk/2017/09/29/sorenson_fined_3m_outage/

4) DDoS attacks against large service providers that really shouldn't be DDOS'able https://techcrunch.com/2016/10/21/many-sites-including-twitter-and-spotify-suffering-outage/ 


On Wed, Oct 4, 2017 at 3:47 PM, Landfield, Kent <Kent_Landfield@mcafee.com> wrote:

Additionally, it would be useful for all to think of examples, real or otherwise, that we could use to flush out the understanding of what conditions justify a services-based CVE. There are some there but it would be good to expand these. 

 

 

 

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of "Andy Balinsky (balinsky)" <balinsky@cisco.com>
Date: Wednesday, October 4, 2017 at 4:42 PM
To: Kurt Seifried <kseifried@redhat.com>
Cc: Art Manion <amanion@cert.org>, "Adinolfi, Daniel R" <dadinolfi@mitre.org>, cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE For Services

 

So, on the call today, we discussed this briefly, and decided that it will be an agenda item in 2 weeks.

 

Please look over the document and discuss on the list, or add examples, or suggest updates to the doc.

 

Silence will be construed as agreement with what is written there.

 

Andy

 

 

On Oct 4, 2017, at 10:12 AM, Andy Balinsky (balinsky) <balinsky@cisco.com> wrote:

 

FYI, I have updated the summary document for the CVE for Services discussion.

 

Feel free to make changes, comment, add to the Pros or Cons section or the Examples section if I haven't captured a good summary of the on-list discussions there.

 

Andy

 

On Sep 29, 2017, at 3:12 PM, Kurt Seifried <kseifried@redhat.com> wrote:

 



On Fri, Sep 29, 2017 at 2:04 PM, Art Manion <amanion@cert.org> wrote:

On 9/26/17 12:26 PM, Kurt Seifried wrote:

1) we for sure let service CNAs self assign (these are the mature ones obviously that will play nice in most cases I hope, in theory an evil company could become a CNA in order to quash any claims of CVEs in their services, but hopefully that doesn't happen)

 

2) we for sure assign CVEs if the claimant can prove their claim (e.g. "Do X/Y/Z and bad thing happens")


Agree with both of these, sufficient evidence of vulnerability exists (admission by vendor, PoC).

I'll note that testing live web sites in many jurisdictions, including the US, can be legally risky.

3) we consider CVEs where the claimant makes a claim but does not have strong evidence, we try to talk to the service provider, we see how that goes and depending on the evidence/etc. a CVE may or may not be assigned.


#2 is easier for product vulnerabilities.

#3 is a problem for product or service vulnerabilities where neither the vendor nor a third party can corroborate the claim.  While there's an argument to be made for "name all the things right away and later mark them disputed or rejected," CVE historically has taken an approach of "wait for the dust to settle then name whatever is left standing."  I don't see it as CVE's role to validate vulnerabilities, that is the job of (some) CNAs, vendors, researchers, and others.

I'm in favor of being able to assign CVE IDs to service vulnerabilities.  But I'd happily accept a cautious approach, generally not assigning for case #3.

 

Yeah, we can definitely start with the easy case(s) and then see how things go (witness the DWF: I'm trying to avoid embargoed CVEs because they're a pain =). 

 


There was discussion about a "this is a service vul" flag, is that still on the table?

 

If we go with CVE for this I would suggest we not only use a service flag (e.g. "product_type" is "end_user_software" and "service" for now or something along these lines) AND we set aside a block (say CVE-YEAR-2000000-2999999) for these giving people another way to ignore them if they want to.

 


Regards,

 - Art


 



 

-- 


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

 

Andy Balinsky (balinsky)

PSIRT Engineering

 

 

 

 

Andy Balinsky (balinsky)

PSIRT Engineering

 

 

 




--
Kurt Seifried
kurt@seifried.org

Page Last Updated or Reviewed: October 05, 2017