mailing list archives
Re: Strange CVE situation (at least one ID should come of this)
From: Kurt Seifried <kseifried () redhat com>
Date: Mon, 29 Oct 2012 14:01:24 -0600
-----BEGIN PGP SIGNED MESSAGE-----
On 10/26/2012 01:54 PM, Josh Bressers wrote:
This Squirrelmail plugin came to my attention a few weeks back:
It's from 2004, which is suspect in itself, but I took a look after
someone asked. It's pretty scary in there.
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 file.
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?
I mailed the Squirrelmail security team. They never responded.
Regardless of their response though, the plugin site says it has
been downloaded more than 100K times, so I suspect it's still in
use somewhere. My goal in this CVE request is to raise awareness so
hopefully people stop using this (and get the Squirrelmail guys to
remove it from their site).
My thoughts on this:
1) Old software like this almost certainly has exploitable flaws.
Evidence: Almost all software has exploitable flaws. New attacks have
been found that the developers didn't even know about. so chances are
they are vulnerable to some of them (e.g. XSS still affects almost all
software, and it's well known, CSRF has become well known and also
affected or still affects most web based software, who knows what is
next). So I think it's safe to say that software that is not
maintained, especially certain classes of software known for generally
poor security (e.g. web plugins written in PHP) can be considered as
vulnerable, but of course we don't have proof, just a very strong
statistical inference (in that to date for example virtually all
software has been found vulnerable to something, especially certain
classes like PHP based web plugins).
2) We can audit the software to find vulnerabilities, proving that it
is indeed vulnerable. However this does not scale, and is resource
3) Assigning CVE's to known bad software is incredibly valuable as not
only does it allow us to track specific technical vulnerabilities, but
in general gives people evidence needed to stop deployment/use of
highly risky software (i.e. "this software package currently has X
CVE's unfixed, therefore it will create a significant risk and we
should not deploy or use it").
4) There is a lot of extremely popular software (certain wordpress
plugins. embedded code like timthumb.php, etc.) that isn't well
maintained (if at all) and has no third party vendor looking out for
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
maintained for 5+ years I'd be willing to bet a large sum of money
that if we started auditing them, every single one would have at least
one CVE worthy vulnerability.
The second question I have is:
Q2) Should we consider software that has a high probability of
containing a flaw, AND process related vulnerabilities (aka no
maintenance is being done) as part of CVE? e.g. software that is not
actively maintained, at some point will need a fix. Not having anyone
to maintain it means that a patch may not be created at all, or if it
is created may take a significant amount of time (since someone has to
learn the software well enough to patch it, QE/QA it, etc.) and
distribution will be a problem since the upstream official site may
not be available to use for distribution (so where do people actually
download the fix?).
Some more thoughts/comments:
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.
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
warn people allowing an informed choice (e.g. "we audited it and found
it to be ok" or "we installed that 5 years ago and forgot about it.
maybe we should evaluate some alternatives").
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
political concerns ("you called my software unmaintained! it is
maintained! it's perfect! prove that it is bad!") coming into play,
but I suspect that won't be much of an issue since by definition we're
dealing with dead software/dead projects here (and CVE has a dispute
mechanism in place).
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-----