[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <508EE094.3090705@redhat.com>
Date: Mon, 29 Oct 2012 14:01:24 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Josh Bressers <bressers@...hat.com>, coley <coley@...re.org>
Subject: Re: Strange CVE situation (at least one ID should
come of this)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/26/2012 01:54 PM, Josh Bressers wrote:
> Hello,
>
> This Squirrelmail plugin came to my attention a few weeks back:
> http://squirrelmail.org/plugin_view.php?id=117
>
> 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).
>
> Thanks.
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
intensive.
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
it/maintaining it.
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)
iQIcBAEBAgAGBQJQjuCUAAoJEBYNRVNeJnmThDcP/14wkG8TpBpGQ6ScnAvsOdHr
5RkYEG6+n/MCDVFWt8E68FyIoFTPWSakL7CKLNaD98R/KlUO31R/2OMXVTw5d42N
u4dRvlOG9oHgdjb//rdQHHnzr0JDcalymIx5uSmWnyZnpnE7PVdlr5llXdSYS9sq
Zvc1OfakB+H4Xu97NC+XkZBoagRa1I+ABH6VAkDUu28js2/gTvUOb4JG+GbC44CG
IK1qRk7Jy8DvdWUkMqPNsjymnW76/eDKd+uVw3I3u/Yb5GUaNMzJnMY1hVeQOy+9
bDlm/TgQvDtx8auGXZ4UgIQhroEy+par1jyAaBsW+XFI6tFGFZo87KuvLo/01bxr
qVLUTY4NkmVw207XWFoPv2x4U7cuVs3O2+PL4rWI4auxTwP2A37lMpClDKbuw+/O
lK2xqUq8tdASs/9KHkrJxNMlBiviZt94yMKvDMKxZ4EzWUwaPSf1V/aLU0yml/Jq
nVBVen5T+6wxrz3+58YQOF1f/DOdld2l7xJ0YZ9wkHRi8sDnZugmX/h2mL4MwWJw
LfIaLrTYyJG62AESaOaWfamr+vvr/htzLtON9ZNI8bOZIKiYtKhzTTUb++Ew7hGc
iEW+zlx+O4MG/Q5DRLUb4iYZpDWjnFzl90sPqwYUgz3zFa/eCnnapt5igAxNcaD9
NL9MilUHKSu0erc/zGcg
=XEuu
-----END PGP SIGNATURE-----
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.
