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

Re: CVE program priorities

On Tue, Dec 29, 2015 at 12:56 PM, Art Manion <amanion@cert.org> wrote:
A few collected responses...

On 2015-12-22 15:22, Eugene H. Spafford wrote:

On 2015-12-22 14:28, Kurt Seifried wrote:
> I think we should really split the problem into:
>
> 1) assigning CVEs
>
> 2) the CVE database
>
> as #1 can happily exist with or without #2.

This is an important point.  #1 is identification, this thing is called
CVE-X.  Some amount of information (#2) is needed to perform #1 --
uniqueness determination at least.  That amount could be reduced at the
cost of more duplicates or overall less short-term quality for #2. 

So one note: most Open Source security issues have a CVE associated with either the code commit the created the vuln, the code commit that fixed the vuln, or a security report that typically at least identifies the vulnerable function and describes what happened (usually with a code snippet example). So at least from the Open Source side mostly what we care about is "what is the vulnerable code" because then anyone can check if they are vulnerable or not with relative ease and a high degree of certainty. 

A perfect example of this being some vulns in giflib's giffix utility, we (Red Hat) ship a product which includes PhantomJS which in turn embeds giflib, so I crack the source rpm open to see what version of giffix is included in our PhantomJS and good news is, it doesn't include giffix, just the giflib library bits. 

The current state of http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7555 is the "reserved" statement.

Now obviously the closed people are in a bit more of a difficult position, without a security report that lists reliable version affected/not affected information, or a reproducer to test it they are largely in the dark. But this problem currently exists because I doubt Mitre is actively verifying/testing/writing reproducers for closed source reports (if they are I'd love to know) but is instead consuming security reports from vendors/etc. like the rest of the world.

--
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
Page Last Updated or Reviewed: December 30, 2015