Home page logo

oss-sec logo 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.


Attachment: signature.asc
Description: Digital signature

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]