Re: [cobalt-security] OpenSSL Advisory?

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Charlie,

> Anyone seen or concerned about the OpenSSL advisory posted to bugtraq
> today? I see that redhat has released an updated rpm for the new release,
> but haven't heard anything in either the Cobalt or the Ensim circles about
> people scurrying to get it installed.

Well, OpenSSL updates are nasty as god-knows-what is compiled against it. 
Either statically or dynamically.

Lets see which services on a RaQ550 link dynamically against OpenSSL's 
libcrypto.so.1 - just as an example:

        openssl   is needed by ucd-snmp-4.2.3-2C1
        libcrypto.so.1 is needed by cyrus-sasl-1.5.24-C5
        libcrypto.so.1 is needed by ucd-snmp-4.2.3-2C1
        libcrypto.so.1 is needed by ucd-snmp-utils-4.2.3-2C1
        libcrypto.so.1 is needed by lftp-2.3.9-1
        libcrypto.so.1 is needed by postgresql-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-contrib-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-devel-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-libs-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-perl-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-python-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-server-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-tcl-7.2.3-1C1
        libcrypto.so.1 is needed by postgresql-tk-7.2.3-1C1
        libcrypto.so.1   is needed by wget-1.8.2-4.70
        libcrypto.so.1 is needed by apache-1.3.20-Alpine_1C12stackguard
        libcrypto.so.1 is needed by openssl-python-0.9.6-2C5
        libcrypto.so.1 is needed by sendmail-8.11.6-SOL3
        libcrypto.so.1 is needed by php-4.0.6-C5_RaQ550
        libcrypto.so.1 is needed by bind-9.2.1-0.7xstackguardC2
        libcrypto.so.1 is needed by bind-utils-9.2.1-0.7xstackguardC2


The stock services where I'd be worried are Apache and the Mod_SSL module to 
be more specific. However, when you look at the RedHat advisory which was 
posted to Bugtraq, then you see this explanation:

------------------------------------------------------------------------------------------------
Quote:

A remote attacker could trigger this bug by sending a carefully-crafted SSL 
client certificate to an application. The effects of such an attack vary 
depending on the application targetted; against Apache the effects are 
limited, as the attack would only cause child processes to die and be 
replaced. An attack against other applications that use OpenSSL could result 
in a Denial of Service.

------------------------------------------------------------------------------------------------

So against Apache the effect is limited to a DOS attack. 

Lets look at another crucial service: OpenSSH. Both PKGmaster.com and 
Solarspeed.net have OpenSSH PKGs which are statically compiled against a now 
vulnerable OpenSSL.

The question is of course if the bug is exploitable under these conditions or 
not. Can it be DOS'ed? Yeah, probably. Can it be exploited to gain root 
access? I doubt it, but who knows?

In regards to OpenSSH I'll play it safe and will release new OpenSSH PKG's 
which are statically compiled against OpenSSL-0.9.7c shortly. I just want to 
wait a little for the dust to settle, because that'll be the 4th rebuild of 
OpenSSH in two weeks. :o( 

There are other services which link statically to OpenSSL. Some of them are 
not installed by default on a RaQ, some are. When you look at cURL, lftp or 
wget, then it's difficult to imagine how they could be exploited due to this 
vulnerability.

So all in all this OpenSSL vulnerability should be addressed along the way, 
but as it presents itself at the moment it's nothing I'd have a sleepless 
night over.
 
-- 

With best regards,

Michael Stauber