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

RE: CVE for hosted services

just for the sake of 'argument', and more of an exercise to see what 
this 
is leading to.

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.

In many ways, this entry would be one of the easiest to write given the 
details, and yet lacks a critical bit of info.

.b



On Thu, 23 Feb 2017, Booth, Harold (Fed) wrote:

: I promised on the call to describe a use case for services. Here is 
one with some branching:
: 
: A popular service/site has a vulnerability for some period of time. 
This vulnerability created an exposure for users/consumers of the 
service/site. The users/consumers would like to go back and determine 
if they have been impacted because of this exposure. In order to do 
this they will need a date range and a description of the problem (i.e. 
what part of the service was vulnerable), potential impacts on them 
(the users), and potential (or actual) exploits. While it would be 
beneficial if the service provider had all of this information, they 
may not, and now there is a need to have a long-lived identifier to 
coordinate the discussion among several different stakeholders (I would 
also argue that just communicating between the service provider and the 
customer is enough reason for the identifier). I agree collecting this 
information may not be easy at the moment, but I don't think that 
doesn't mean it isn't desirable to have it. Minimally, I think this use 
case demonstrates t
 he need for an identifier. Perhaps once it is demonstrated that this 
information is important then it will be more routine for it to be 
tracked and available.
: 
: Hopefully, I am not too far afield with this.
: 
: -----Original Message-----
: From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Art Manion
: Sent: Wednesday, February 22, 2017 4:39 PM
: To: jericho <jericho@attrition.org>; Pascal Meunier 
<pmeunier@cerias.purdue.edu>
: Cc: cve-editorial-board-list 
<cve-editorial-board-list@LISTS.MITRE.ORG>
: Subject: Re: CVE for hosted services
: 
: On 2017-02-22 16:19, jericho wrote:
: > On Wed, 22 Feb 2017, Pascal Meunier wrote:
: > 
: > : I'm afraid that the description of the entries, for issues on 
: > services
: > : like facebook.com, would be typically very vague and 
unverifiable.  
: > I'm
: > : rather annoyed by existing entries that read like "a problem in 
X, 
: > but
: > : different from CVE-1234-5678 and CVE-1234-7890".  What is the 
issue? 
: > : What lessons could be learned from this?  What should we teach 
not 
: > to
: > : do, or teach to do better?  No idea.
: > 
: > Good point.
: > 
: > Also consider that such descriptions would almost never carry 
version 
: > information and be based more on *approximate* dates. We often hear 
: > Facebook "fixed a vuln" but days or weeks after it really happened. 
: > Since versions are a huge tool for determining potential duplicate 
: > issues, without that would be painful.
: 
: Agreed, there's likely pain for cataloging purposes (de-duplication) 
and low value for engineering purposes.  But the overriding factor for 
me is
: *identification* (and yes, for ID to work, it has to be possible to 
distinguish different vulnerabilities).
: 
: CVE throws light on vulnerabilities.  Probably weekly, without 
looking, I come across issues that don't have CVE IDs assigned and 
therefore aren't noticed by people who might benefit from knowing.  I 
make a note to send in a minimum viable entry, but haven't yet.
: 
: Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, 
large services freely admit they have vulnerabilities, and fix them?
: Users/customers actually like such transparency?
: 
: Vulnerabilities are common and everywhere and aren't terribly special 
individually.  Name them and go about your choice of defensive 
activities, probably including vulnerability management.
: 
:  - Art
:
Page Last Updated or Reviewed: February 24, 2017