Re: CVE for hosted services

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

In this case you're talking about incident IDs, not CVE IDs, because the
second and third ones could be the same core vulnerability as the first,
just badly patched or badly protected.  In addition, two similar
findings at the same time could actually be different vulnerabilities so
you'd need 2 CVEs to do it properly.  Or do we not care anymore, as I
recall seeing a single CVE for multiple vaguely defined vulnerabilities?

For every incident, without visibility inside the remote black box that
is providing the service, we have little to no idea which
vulnerabilities are involved, and we can't ID them.  We can only ID the
findings of problems.  Although giving IDs to incidents and findings is
very useful, that's outside the scope of the CVE.  It's like we have a
hammer (CVE IDs) and everything looks like the proverbial nail now.

I suggest the creation of something else to identify incident, report or
finding IDs.

Pascal


On Fri, 2017-02-24 at 10:11 -0700, Kurt Seifried wrote:
> For example someone finds another memory disclosure in CloudFlare, 
> and then
> another person finds a third one. Are we talking about A, B or C?
> CLoudBleed 1? The thing after CloudBleed? If they had CVE's or an
> equivalent identifier it would be much easier. Especially as I have 
> to now
> interact with other vendors (Hey Atlassian, do you deliver JIRA via
> CloudFlare at all and are you affected by CloudBleed?).
> 
> Especially as the data leaked from CloudBleed is now in all sorts of 
> data
> caches around the internet (search providers, maybe archive.org, 
> etc.), so
> we'll need to talk about this off and on for potentially the next few
> years.
> 
> On Fri, Feb 24, 2017 at 9:03 AM, Millar, Thomas 
> <Thomas.Millar@hq.dhs.gov>
> wrote:
> 
> > How do I use a CVE for a service vuln to check if my environment was
> > affected and if so, that my ops have applied the proper remedies?
> >
> >
> >
> > Tom Millar, US-CERT
> >
> > Sent from +1-202-631-1915 <(202)%20631-1915>
> > https://www.us-cert.gov
> >
> > ------------------------------
> > *From:* owner-cve-editorial-board-list@lists.mitre.org on behalf of 
> > Kurt
> > Seifried
> > *Sent:* Friday, February 24, 2017 3:44:39 PM
> > *To:* Art Manion
> > *Cc:* jericho; Booth, Harold (Fed); cve-editorial-board-list
> > *Subject:* Re: CVE for hosted services
> >
> > So uhh I'll just leave this example here:
> >
> > https://www.google.ca/search?q=cloudflare+cloudbleed
> >
> > I know for example on the CloudSecurityAlliance side I now need to
> > forcibly reset every password for all our websites, and look at the 
> > third
> > parties we do auth from (e.g. FaceBook/Linkedin) to see if they are
> > affected (not that there is much we can do other than notify 
> > people).
> >
> > On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <amanion@cert.org> 
> > wrote:
> >
> >> On 2017-02-23 19:05, jericho wrote:
> >>
> >> > https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
> >> >
> >> > Harold, how would you write a CVE-ish description of this, in the
> >> context
> >> > of moving CVE to site-specific issues? The service and info 
> >> > disclosed is
> >> > the easy part. Then what? Do you also mention some of the 
> >> > services that
> >> > use Cloudflare? Some businesses may know, where individuals do 
> >> > not (e.g.
> >> > 1Password is hosted on it). What date range do you put down for 
> >> > this?
> >> You
> >> > know the fix date, but not the start date. This goes back to the 
> >> > problem
> >> > of making such entries useful to companies trying to determine 
> >> > risk.
> >>
> >> Not answering your question, but:
> >>
> >> This issue should get a CVE ID so the world can talk about it and 
> >> have
> >> confidence they're talking about the same "it."  The description 
> >> might
> >> be tricky, but the description is primarily to 
> >> catalog/de-duplicate, not
> >> to help assess risk.
> >>
> >> CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, 
> >> RBS,
> >> CERT, a CloudFlare customer) can add to the severity/risk 
> >> assessment.
> >>
> >>  - 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
> >
> 
> 
>