[Pkg-openssl-devel] Re: [jaenicke@openssl.org: Re: Potential security hole in openssl]

[Bodo Moeller]

On Thu, Mar 01, 2007 at 06:00:52PM +0000, Julian Gilbey wrote:

>> ----- Forwarded message from Lutz Jaenicke <jaenicke at openssl.org> -----
>> 
>> From: Lutz Jaenicke <jaenicke at openssl.org>
>> To: openssl-team at openssl.org
>> Cc: security at debian.org, openssl at packages.debian.org,
>> 	openssl-security at openssl.org
>> Subject: Re: Potential security hole in openssl
>> 
>> 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.
>>> [...]
>> 
>> 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...

> s_client works fine :-/

Can you link the application with libefence.a?  If done correctly,
this will make it a lot slower; but more importantly, quite possibly
you'll observe a segmentation fault earlier in the program flow:

< (gdb) bt
< #0  0xb7ef5ab3 in ssl2_enc (s=0x806cc00, send=0) at s2_enc.c:146
< #1  0xb7ef6416 in ssl2_read_internal (s=0x806cc00, buf=0xbfe6c480, len=65536,
<     peek=0) at s2_pkt.c:266
< #2  0xb7f0f898 in SSL_read (s=0x30, buf=0xbfe6c480, num=65536) at ssl_lib.c:871
< #3  0x0804d09d in stream_copy (pts_from=0x8062e10, pts_to=0x8062810)
<     at ptstream.c:153
< #4  0x0804a744 in cpio (stream1=0x8062810, stream2=0x8062e10) at io.c:151
< #5  0x08049d99 in main (argc=Cannot access memory at address 0x30
< ) at proxytunnel.c:433
< (gdb) p ds
< $1 = (EVP_CIPHER_CTX *) 0x8083e90
< (gdb) p ds->cipher
< $2 = (const EVP_CIPHER *) 0x2f4c5353
< (gdb) p ds->cipher->block_size
< Cannot access memory at address 0x2f4c5357

This looks like the original value of ds->cipher has been overwritten
at some point, possibly due to a buffer overrun that happened earlier.
(Of course, this might very well be some other weird bug.)

Bodo