On Mon, 11 Jul 2011, Dennis Kibbe wrote:
> On Sun, 2011-07-10 at 12:00 -0400, R P Herrold wrote:
>> There are are no publicly known SSL issues in the openssl
>> maintained by CentOS
>>
>> Please state the CVE, or if a private zero day, Lisa, please
> One thing that people might not realize is that Red Hat back ports
> security fixes so you can't just look at the version number and assume
> that if it's not the latest it's flawed.
That is not unique to Red Hat derived matter. It is true with
anything relying on external banners, whether from an external
package name, or from a greeting banner advertised, only
publishes what its author wants to say ...
We formerly offered shell accounts at an ISP I adminned, and
we consciously editted /etc/issue to advertise that the host
was a plain old i386 architecture, when in point of fact it
was on an Alpha
People regularly carried in exploits for that particular
version of Red Hat Linux, or RPMs for the i386 architecture,
and sought to install or unpack and run them ... it did not
work of course, and it permitted us to identify people who
needed closer attention by looking for the core files left
behind
In a similar fashion, for colocated hosting, a client will
occasionally send along the results from a naiive
vulnerability scanner service, that is merely reading such
banners. In speaking with the people selling such snake oil,
they are at least honest enough to admit that they don't have
working exploits, but are rather just a banner scanning
service, building a list from reading various mailing lists
First we check if the report is accurate; as they almost never
are [when they are, they imply that some updates were needed],
we therefore change the banners displayed, and silence the
report --- one received a few weeks ago asserted a
vulnerability in our "Linux IIS webserver" ... how else to fix
it? ;)
In the case of Lisa's asserted exploit against the current
CentOS openssl, one might trivially see what CVE are
addressed, and which are not thus:
rpm -q --changelog openssl | grep CVE
which yields for this CentOS 5 box:
[herrold@bronson ~]$ rpm -q --changelog openssl | grep CVE
- fix CVE-2010-4180 - completely disable code for
- fix CVE-2009-3245 - add missing bn_wexpand return checks (#570924)
- fix CVE-2009-3555 - support the safe renegotiation extension and
- fix CVE-2010-0433 - do not pass NULL princ to krb5_kt_get_entry which
- mention the RFC5746 in the CVE-2009-3555 doc
- fix CVE-2009-2409 - drop MD2 algorithm from EVP tables (#510197)
- fix CVE-2009-4355 - do not leak memory when CRYPTO_cleanup_all_ex_data()
- fix CVE-2009-1386 CVE-2009-1387 (DTLS DoS problems)
- fix CVE-2009-1377 CVE-2009-1378 CVE-2009-1379
- fix CVE-2009-0590 - reject incorrectly encoded ASN.1 strings (#492304)
- fix CVE-2008-5077 - incorrect checks for malformed signatures (#476671)
- fix CVE-2007-3108 - side channel attack on private keys (#250581)
- fix CVE-2007-5135 - off-by-one in SSL_get_shared_ciphers (#309881)
- fix CVE-2007-4995 - out of order DTLS fragments buffer overflow (#321221)
- CVE-2006-2940 fix was incorrect (#208744)
- fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276)
- fix CVE-2006-2940 - parasitic public keys DoS (#207274)
- fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940)
- fix CVE-2006-4343 - sslv2 client DoS (#206940)
- fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180)
[herrold@bronson ~]$
=================
Lisa? Still waiting on a reply to:
> Please state the CVE, or if a private zero day, Lisa, please
> state the vector so I may set up a unit running the allegedly
> vulnerable service or services [ie over http, smtp. pop,
> whatever] for you to demonstrate this assertion
-- Russ herrold
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)