Re: CVE for hosted services

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

On Fri, 2017-02-24 at 10:36 -0700, Kurt Seifried wrote:
> On Fri, Feb 24, 2017 at 10:34 AM, Pascal Meunier 
> <pmeunier@cerias.purdue.edu
> > wrote:
> 
> > 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
> >
> 
> Not necessarily. They could be completely separate things/services 
> (TBH I
> have no idea how cloudflare internally operates, it could be a 
> monolithic
> binary for all I know).
> 

The point is we can't know, unless as you suggest further below the
provider actively helps with CVE assignment -- in which case they are
our hmm, proxy, into the problem.  Even better if the reporter and
provider work together, but I don't think we can count on that often.
I'll fall back on the suggestion by someone else (paraphrasing) that the
CVE IDs be given when it makes sense for such cases, without trying to
systematically cover the entire space, making this an "optional scope".
To me it makes sense only when the vulnerability can be identified in
software running somewhere, not just when any security problem has been
found.

> 
> 
> 
> > 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.
> >
> 
> Ideally the provider would help with CVE assignment (much like 
> cloudflare
> wrote a large blog entry) so that it is done correctly. A lot of these
> providers care about being seen as security conscious/responsible, 
> it's a
> major competitive edge.
> 
> 
> >
> > 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
> > > >
> > >
> > >
> > >
> >
> >
> >
> 
>