oss-sec mailing list archives
Re: Strange CVE situation (at least one ID should come of this)
From: Seth Arnold <seth.arnold () canonical com>
Date: Mon, 29 Oct 2012 23:01:52 +0100
On Mon, Oct 29, 2012 at 02:01:24PM -0600, Kurt Seifried wrote:
So the first question I have is: Q1) Do we need to audit software to prove that it is vulnerable? Or is a statistical model enough? e.g. for PHP based web plugins, not
I can't argue against the statistical model though it does rather reduce the value of CVE as naming a specific vulnerability if they start getting assigned for "eww this smells". There may be one easily exploitable remote root flaw, there may be thousands of reliability and information disclosure flaws, but hiding them all under one "old and stinky" CVE doesn't feel like a significant improvement.
We can assign a CVE with a description along the lines of "Software X has not been actively maintained since release Y on date Z. Software X is comprised of some stuff and built in language Z which is known to commonly result in security flaws (possibly list what kind, e.g. XSS/buffer overflow, etc.)." Maybe start with a generic cut off date of say 5 years, and start listing stuff as people find/notice them. If a program ever comes back into maintenance and release a new version then the old CVE would be there as a warning, and moving forwards people would be able to make a much more informed choice.
To turn this on its head: qmail is an MTA (historically trouble) written in C (historically trouble) and has not had a stable release in 14 years (going strictly by Wikipedia). But I do not think qmail deserves a CVE simply by this basis.
In effect this would be a blacklist/greylist of software, and by using CVE it would be able to piggy back on the existing CVE ecosystem (no better word to use), e.g. scanners would pick up the old versions and
I'll grant that the CVE ecosystem is large and potentially very powerful Force For Good, if deployed this way. But when a consumer asks, "Is CVE-2013-F00F fixed?" and the answer is "one guy put together three releases the last two months, fixing one bug each", what _is_ the answer? "Yes" because there is a responsive maintainer? Or "No" because probability dictates there is likely more cruft yet to be found? Or "No" because two months is insufficient data to draw a conclusion?
I realize this looks a LOT like feature creep with respect to CVE, but I think it falls into the definition of a vulnerability closely enough that it makes sense/won't result in a huge mess. I can of course see
I like the specificity of today's CVE. I also think your idea has merit -- there is too much never-loved software out there -- but I don't think CVE is the correct lever to attack it. Thanks
Attachment:
signature.asc
Description: Digital signature
Current thread:
- Strange CVE situation (at least one ID should come of this) Josh Bressers (Oct 26)
- Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Oct 29)
- Re: Strange CVE situation (at least one ID should come of this) Seth Arnold (Oct 29)
- Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Oct 29)
- Re: Strange CVE situation (at least one ID should come of this) Steven M. Christey (Oct 30)
- Re: Strange CVE situation (at least one ID should come of this) Henri Salo (Oct 30)
- Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Oct 30)
- Re: [security] [oss-security] Strange CVE situation (at least one ID should come of this) Greg Knaddison (Oct 31)
- Re: Strange CVE situation (at least one ID should come of this) Seth Arnold (Oct 29)
- Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Oct 30)
- Re: Strange CVE situation (at least one ID should come of this) Steven M. Christey (Oct 31)
- Re: Strange CVE situation (at least one ID should come of this) Josh Bressers (Nov 02)
- Re: Strange CVE situation (at least one ID should come of this) cve-assign (Nov 02)
- Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Oct 29)