RE: definitions for what is CVE worthy with downloads/installs and containers

[Common Vulnerabilities & Exposures <cve@mitre.org>]

Kurt –

 

We agree completely with you, and we provided CVE-2016-5119 to the requester last month.

 

Regards,

 

The CVE Team

 

From: Kurt Seifried [mailto:kseifried@redhat.com]
Sent: Wednesday, June 08, 2016 12:23 PM
To: Common Vulnerabilities & Exposures <cve@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: definitions for what is CVE worthy with downloads/installs and containers

 

 

 

On Tue, Jun 7, 2016 at 9:14 PM, Common Vulnerabilities & Exposures <cve@mitre.org> wrote:

Kurt –

 

As you are well aware, CVE assignment is never an exact science. The following is a description of our current practice:

 

·         The question of whether it is "software acting exactly as it is designed" depends on who sends the CVE ID request. For example, it is plausible for a vendor's server to offer the same executable code (or update service) through both HTTP and HTTPS, and the URL hardcoded into a client-side product was -- by design -- supposed to start with https, but it started with http by accident. Thus, if it is a vendor-initiated request for a CVE ID to tag a required security update for their customers, then the CVE ID request is always accepted.

·         If the origin of the CVE ID request seems unrelated to the party that wrote the code, then (sometimes but not 100% of the time) the CVE ID request is rejected with a suggestion to consult with the vendor.

·         It would be hard to achieve 100% rejections, even if a CNA wanted to, because the person sending the CVE ID request may neglect to mention, or may be unwilling to mention, the precise nature of the problem. A large fraction of the population believes that it is always a vulnerability for any product to continuously make requests for executable code over unencrypted HTTP, with no other integrity protection, and execute code whenever a response is received. Because that much is obvious in their world view, their vulnerability description may focus on other details, such as file-format manipulation, etc.

·         Our prevailing opinion is that, for this HTTP/executable-code scenario, the best a CNA can do is assign CVE IDs in cases where they believe CVE consumers want those IDs to exist. If the requester sends a credible description of high exploitation likelihood, and there is no counterclaim from the vendor itself that this is "software acting exactly as it is designed," then it qualifies for a CVE ID.

 

By definition if people are asking for CVE's for a security vulnerability they want them to exist. As well as a user of various Open Source and closed source products I want to be an informed consumer, the easiest way to do this currently is with CVEs (issues are consolidated in a single easily searched database, as opposed to many vendor sites which (intentionally?) make it hard to find security information about their products.

  

This matches what happened for ASUS (the vendor refused to respond at all). If another requester does not describe exploitation likelihood or asserts that there is essentially no exploitation likelihood, and there is no clarification from the vendor, then the request can be rejected on the "software acting exactly as it is designed" grounds.

 

In other words, existence of a CVE ID should depend a little less on a comprehensive theory of what a vulnerability is, and depend a little more on judgment about whether the ID will help real-life organizations with risk management. This requires a little more work from the CNA, but makes CVE more useful than with either the 100% accept or 100% reject options.

 

So for example we have KeePass 2 which refuses to fix their HTTP update check because it would cost the developer ad revenue:

 

http://www.engadget.com/2016/06/04/keepass-wont-fix-security-hole-due-to-ads/

 

so not only do we have a known security vulnerability, but we have a vendor flat out refusing to fix it, now I'm going to assume users of KeePass2 would like to know this, and I find it unlikely the vendor will inform them. As such a CVE (with it's resulting propagation to vulnerability management services) is one of the better ways to ensure people get notified. 

 

 

 

Regards,

 

The CVE Team

 

 

 

 

--

 

--
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