Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Oct 2012 19:45:24 -0600
From: Kurt Seifried <>
Subject: Re: Strange CVE situation (at least one ID should
 come of this)

Hash: SHA1

On 10/29/2012 04:01 PM, Seth Arnold wrote:
> 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.

Right but the problem is people aren't going to audit these stinky old
softwares to find CVE's, it's just not worth it mostly (what's the

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

Hence the model. You take things into account like what language was
used, what the software does, it's track record, and the person/team
writing it and so on. In this case DJB has a pretty good track record,
so statistically speaking qmail is on the safer side and probably
doesn't need a CVE anytime soon. This isn't simple "if release >=5
years assign cve=true" =).

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

1) I suspect we'll be assigning this to very dead software so I think
it's highly unlikely that any updates ever got shipped.
2) if it happens it's basically "fixed" by the new release. but again
I seriously doubt we'll run into this anytime soon.

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

Me too. But this is already being heavily eroded by firms like Oracle:

The reality is we already have hundreds of CVE entries with absolutely
no significant details other than a product name and version and vague
terms as whether or not Confidentiality/Accessibility/Integrity might
be affected.

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

The problem is we have this ecosystem of CVE software from scanners
like Nessus to firms like iDefense/iSIGHT. Using CVE would quickly
give this old and problematic software problems high visibility, CVE is:

"International in scope and free for public use, CVE is a dictionary
of publicly known information security vulnerabilities and exposures."

> Thanks

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)


Powered by blists - more mailing lists

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.