[Pkg-openssl-devel] Re: Potential security hole in openssl

[Lutz Jaenicke]

On Wed, Feb 28, 2007, Julian Gilbey wrote:

> I've been trying to get proxytunnel to tunnel via HTTPS.  I've been
> trying the latest version of proxytunnel (1.7.0, available from
> proxytunnel.sourceforge.net), but the openssl library segfaults.  (I
> am working on a Debian testing system.)  I have also tested this on
> the unstable version - see below.
> 
> I don't know whether this is a potential security hole in openssl, but
> here is a detailed description of what happened:
> 
>  burnside:~ $ proxytunnel -v -p localhost:443 -d burnside:8080 -E
>  SSL client to proxy enabled
>  Local proxy localhost resolves to 127.0.0.1
>  Connected to localhost:443 (local proxy)
>  Tunneling to burnside:8080 (destination)
>  Connect string sent to local proxy:
>  -> CONNECT burnside:8080 HTTP/1.0
>  -> Proxy-Connection: Keep-Alive
>  Data received from local proxy:
>  <- HTTP/1.0 200 Connection Established
>  <- Proxy-agent: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
>  Tunnel established
>  Segmentation fault
>  burnside:~ $

On my Debian etch system I get:
ljaenicke at lutzpad:~/pt/proxytunnel-1.7.0$ ./proxytunnel -v -p localhost:443 -d
burnside:8080 -E
SSL client to proxy enabled
Local proxy localhost resolves to 127.0.0.1
Connected to localhost:443 (local proxy)
Tunneling to burnside:8080 (destination)
Connect string sent to local proxy:
-> CONNECT burnside:8080 HTTP/1.0
-> Proxy-Connection: Keep-Alive
Data received from local proxy:
<- HTTP/1.1 302 Found
HTTP return code: 302 Found
*** glibc detected *** malloc(): memory corruption: 0x0807d0c0 ***
Aborted

So something seems to be odd here indeed.

Some more comments below...

> I rebuilt the etch openssl package (version 0.9.8c-4) library with no
> optimisation and install a debugging version to see whether that helps
> when I do a backtrace...
> 
> How interesting: it fails when trying to determine the block size:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7ef0963 in ssl2_enc (s=0x806cae8, send=0) at s2_enc.c:140
> 140             bs=ds->cipher->block_size;
> (gdb) bt
> #0  0xb7ef0963 in ssl2_enc (s=0x806cae8, send=0) at s2_enc.c:140
> #1  0xb7ef1055 in ssl2_read_internal (s=0x806cae8, buf=0xbf83fe50, len=65536,
>     peek=0) at s2_pkt.c:266
> #2  0xb7ef11c7 in ssl2_read (s=0x806cae8, buf=0xbf83fe50, len=65536)
>     at s2_pkt.c:309
> #3  0xb7f100fa in SSL_read (s=0x806cae8, buf=0xbf83fe50, num=65536)
>     at ssl_lib.c:871
> #4  0x0804d09d in stream_copy (pts_from=0x8062e10, pts_to=0x8062810)
>     at ptstream.c:153
> #5  0x0804a744 in cpio (stream1=0x8062810, stream2=0x8062e10) at io.c:151
> #6  0x08049d99 in main (argc=78537217, argv=0x8984ec3) at proxytunnel.c:433

Why in hell do we end up in SSLv2 routines???
Ah, I see from proxytunnel:
  meth = SSLv2_client_method();
Using SSLv2 as the one and only method is a bad idea anyway. One should
rather use SSLv23_client_method() to get the best and latest version
available. It is even strongly recommended to disable SSLv2 such that
SSLv3 or TLSv1 are selected. (-> SSL_CTX_set_options()).
Having this said, an application should not crash anyway...

Ok, the effect is reproducable with 0.9.8 from current CVS.

> (gdb) p ds
> $1 = (EVP_CIPHER_CTX *) 0x8083d70
> (gdb) p ds->cipher
> $2 = (const EVP_CIPHER *) 0x2f4c5353
> (gdb) p ds->cipher->block_size
> Cannot access memory at address 0x2f4c5357
> (gdb)

Hmm, 0x2f4c5357 seems to be an odd address to point to...

Using "openssl s_client -ssl2 -connect localhost:443" does not exhibit
any problem, it however doesn't do anything with memory allocations
in the s_client demo application so we might not detect a corruption...

Can you run give s_client a try? If it crashes we could at least
rule out proxytunnel...

Regards,
	Lutz
--
Lutz Jaenicke           jaenicke at openssl.org
OpenSSL Project         http://www.openssl.org/~jaenicke/