mailing list archives
Re: Strange CVE situation (at least one ID should come of this)
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 30 Oct 2012 14:32:18 -0600
-----BEGIN PGP SIGNED MESSAGE-----
On 10/30/2012 11:34 AM, Steven M. Christey wrote:>
On 10/26/2012 01:54 PM, Josh Bressers wrote:
If I was to list the security problems I found after a few
minutes of looking, they are:
* It uses MD5 passwords * The shadow file is directly modified
without locking (which could lead to a race condition) * If you
get the password wrong, it doesn't unlink the empty temporary
None are really a big deal, you *could* run this and probably
never notice these problems.
Fundamentally though, this thing should get one CVE ID that
basically say "don't use this". How have situations like this
been handled in the past?
To have a CVE for "don't use this" is not consistent with
long-existing practice. I don't recall ever intentionally
assigning a CVE for such a thing - after all, CVE is about
vulnerabilities, and "don't use this" is awfully vague.
True, but we've already gone down that road, e.g.:
CVE-2012-2400 Unspecified vulnerability in
wp-includes/js/swfobject.js in WordPress before 3.3.2 has unknown
impact and attack vectors.
Deployment of risky software is effectively a configuration or
asset management issue, which is well outside the scope of CVE.
(Maybe it's more like a Common Configuration Enumeration (CCE)
If anything I think it would fit into CPE
In other words - we really shouldn't use CVE to handle this
problem. It is feature creep, and I believe that it WOULD become a
huge mess. Maybe this would work for some, but not for all of
CVE's consumers, which is a wide variety of people and use cases.
I understand that there is a problem here, though.
True about the mess and not all customers being happy with it.
It looks like Josh laid out at least 3 different security issues in
your initial request. Those can/should get CVEs assigned, even if
there aren't full details. The lack of a vendor CONFIRM reference
or advisory, tells the consumer that the vendor hasn't addressed
Perhaps the OSS community could borrow an idea from one of the
framework vendors with lots of third-party modules - I forget if it
was Joomla or Drupal - who actively maintained a list of poorly
maintained or obsolete software.
In the broadest sense, however, such old software is still useful
for people who are starting in vulnerability research, or just
doing it for fun; many people who audit what MITRE calls "phpGolf"
applications, go on to do more substantive research.
The old software would still be available (unless someone goes through
sourceforge for example and does some serious spring cleaning).
Perhaps it is time to re-examine Crispin Cowan's Sardonix project,
which tried to match vulnerability researchers with open source
projects, in order to build reputations for both.
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Re: Strange CVE situation (at least one ID should come of this) Raphael Geissert (Oct 30)
Re: Strange CVE situation (at least one ID should come of this) Kurt Seifried (Dec 04)