A new workaround for bug 3816: ssl_crtd crash with OpenSSL v...

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 09 May 2013 08:50:05 -0600

Hello,

    According to the squid-user exchange below, OpenSSL v0.9.8y is also
vulnerable. However, it is possible that the stock v0.9.8y is not
vulnerable, but FreeBSD patched it to make it vulnerable, I guess.
Christos, can you reproduce the crash with stock v0.9.8y on Linux (if
you do not have FreeBSD)?

I wonder if we should change strategy from compile-time OpenSSL version
checks to something like this:

   // Temporary ssl for getting X509 certificate from SSL_CTX.
   Ssl::SSL_Pointer ssl(SSL_new(sslContext));
   // Various OpenSSL versions crash on a SSL_get_certificate() call:
   // http://bugs.squid-cache.org/show_bug.cgi?id=3816#c16
   // so we avoid that call by extracting certificate directly:
   X509 *cert = ssl->cert ? ssl->cert->key->x509 : NULL;
   if (!cert)
       return false;

If the "ssl->cert->key->x509" expression is not portable across OpenSSL
versions, perhaps we can detect that at ./configure time and add an
#ifdef guard for _that_ (as opposed to OpenSSL version guards)?

Thank you,

Alex.

On 05/09/2013 08:19 AM, Guy Helmer wrote:
>
> On May 8, 2013, at 10:55 PM, Alex Rousskov <rousskov_at_measurement-factory.com> wrote:
>
>> On 05/08/2013 04:31 PM, Guy Helmer wrote:
>>
>>> I was using squid 3.3.4 on FreeBSD 8.3 with transparent interception
>>> (via ipfw) and ssl bump with success.
>>
>>> After upgrading FreeBSD to 9.1 [...] squid is failing with
>>> segmentation violations and the ssl_crtd helpers are dying.
>>
>>> #7 0xbfbff044 in ?? ()
>>> #8 0x0000000b in ?? ()
>>> #9 0x484eb5c8 in ssl_get_server_send_pkey () from /usr/lib/libssl.so.6
>>> #10 0x484eb68d in ssl_get_server_send_cert () from /usr/lib/libssl.so.6
>>> #11 0x484eb6c4 in SSL_get_certificate () from /usr/lib/libssl.so.6
>>> #12 0x083cb5ef in Ssl::verifySslCertificate (sslContext=0x4a259340,
>>> properties=@0xbfbfd9d8) at support.cc:1422
>>> #13 0x0813d20d in ConnStateData::getSslContextStart (this=0x4a257cd0)
>>> at client_side.cc:3820
>>> #14 0x0814a89e in ConnStateData::httpsPeeked (this=0x4a257cd0,
>>> serverConnection=@0xbfbfdadc) at client_side.cc:3968
>>
>> Smells like an OpenSSL bug that we thought we had a workaround for:
>> http://bugs.squid-cache.org/show_bug.cgi?id=3816
>>
>> The workaround should be in v3.3.4 that you are running but, apparently,
>> it is not sufficient, or our OpenSSL version detection code is failing
>> in your environment. We thought the bug affects OpenSSL versions 1.0.1d
>> and 1.0.1e only.
>>
>> Which OpenSSL version are you building Squid with?
>>
>> What is the OPENSSL_VERSION_NUMBER constant in OpenSSL header files
>> where you build Squid? You can probably run something like "fgrep -RI
>> OPENSSL_VERSION_NUMBER /usr/include/openssl" to figure that out.
>>
>> Which OpenSSL version are you running Squid with?
>
> Under FreeBSD 8.3, it was built and running with OpenSSL 0.9.8q (OPENSSL_VERSION_NUMBER 0x0090811f).
>
> Under FreeBSD 9.1 (stable branch checkout as of 2013-04-10), it is built and running with OpenSSL 0.9.8y (OPENSSL_VERSION_NUMBER 0x0090819fL).
>
> I made this little change to support.cc, rebuilt squid and ssl_crtd, and it seems to be working OK with transparent SSL bumping:
>
> --- src/ssl/support.cc.orig 2013-05-09 08:59:19.000000000 -0500
> +++ src/ssl/support.cc 2013-05-09 09:00:25.000000000 -0500
> @@ -1413,7 +1413,7 @@
> {
> // SSL_get_certificate is buggy in openssl versions 1.0.1d and 1.0.1e
> // Try to retrieve certificate directly from SSL_CTX object
> -#if OPENSSL_VERSION_NUMBER == 0x1000105fL || OPENSSL_VERSION_NUMBER == 0x1000104fL
> +#if OPENSSL_VERSION_NUMBER == 0x1000105fL || OPENSSL_VERSION_NUMBER == 0x1000104fL || OPENSSL_VERSION_NUMBER == 0x0090819fL
> X509 ***pCert = (X509 ***)sslContext->cert;
> X509 * cert = pCert && *pCert ? **pCert : NULL;
> #else
>
> Thanks for the pointer, Alex!
>
> Guy
>
Received on Thu May 09 2013 - 14:50:18 MDT

This archive was generated by hypermail 2.2.0 : Fri May 10 2013 - 12:00:08 MDT