oss-security - Re: Strange CVE situation (at least one ID should come of this)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121029220152.GA2566@hunt>
Date: Mon, 29 Oct 2012 23:01:52 +0100
From: Seth Arnold <seth.arnold@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: Strange CVE situation (at least one ID should
 come of this)

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

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.