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