[openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

Tiantian Liu via RT rt at openssl.org
Thu Oct 1 18:43:17 UTC 2015


Hi,

I did another debug.

I found one strange issue, and post the trace information below:



Loaded symbols for /usr/lib/libcrypto.so.1.0.0

Loaded symbols for /lib/libdl.so.2

Loaded symbols for /lib/i686/nosegneg/libpthread.so.0

Loaded symbols for /lib/i686/nosegneg/libc.so.6

Loaded symbols for /usr/lib/libkrb5support.so.0

Loaded symbols for /lib/libresolv.so.2

Loaded symbols for /lib/libgcc_s.so.1

Loaded symbols for /lib/i686/nosegneg/libm.so.6

Loaded symbols for /lib/ld-linux.so.2

0x00cea402 in __kernel_vsyscall ()

(gdb) c

Continuing.



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread -1232073840 (LWP 17217)]

0x004ba332 in ssl3_clear (s=0xb4964ec8) at s3_lib.c:3069

3069        if (s->next_proto_negotiated) {

(gdb) list

3064        s->s3->num_renegotiations = 0;

3065        s->s3->in_read_app_data = 0;

3066        s->version = SSL3_VERSION;

3067

3068    #if !defined(OPENSSL_NO_TLSEXT) && !defined(OPENSSL_NO_NEXTPROTONEG)

3069        if (s->next_proto_negotiated) {

3070            OPENSSL_free(s->next_proto_negotiated);

3071            s->next_proto_negotiated = NULL;

3072            s->next_proto_negotiated_len = 0;

3073        }

(gdb) where

#0  0x004ba332 in ssl3_clear (s=0xb4964ec8) at s3_lib.c:3069

#1  0x004c5f31 in tls1_clear (s=0xb4964ec8) at t1_lib.c:172

#2  0x004b9f08 in ssl3_new (s=0xb4964ec8) at s3_lib.c:2950

#3  0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154

#4  0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2

#5  0x00000144 in ?? ()

#6  0x00a2edf0 in _dl_runtime_resolve () from /lib/ld-linux.so.2

#7  0x0810c1a9 in SSL_connect_tr_ex (sslc=0x1, msg=0x6d2d326c <Address 0x6d2d326c out of bounds>, pssl=0xc, diag=0x2d336c73 <Address 0x2d336c73 out of bounds>, isDiag=-56 'È') at ../multi_client/source_Host_C_Cod

Previous frame inner to this frame (corrupt stack?)

(gdb) quit

The program is running.  Quit anyway (and detach it)? (y or n) y



I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library.

I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right?



Thanks,

Tyler







-----Original Message-----
From: Matt Caswell via RT [mailto:rt at openssl.org]
Sent: October-01-15 10:52 AM
To: Tiantian Liu
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function







On 01/10/15 15:18, Tiantian Liu via RT wrote:

> Hi,

>

> Good morning! Thanks for your response.

>

> I configured my OpenSSL with '-d' option to enable the debugging information. Where I don't know how to use it during my application running.



Which version of OpenSSL did you download? My version 1.0.1p doesn't match up with the line numbers in your backtrace below, i.e. line 209 in s3_clnt.c is not 'SSL_clear(s);' as it appears to be for you.



> Loaded symbols for /usr/lib/libkrb5.so.3 Loaded symbols for

> /usr/lib/libk5crypto.so.3 Loaded symbols for

> /usr/lib/libptcoresdk.so.2 Loaded symbols for /lib/libcom_err.so.2

> Loaded symbols for /usr/lib/libstdc++.so.6 Loaded symbols for

> /usr/lib/libssl.so.1.0.0 Loaded symbols for

> /usr/lib/libcrypto.so.1.0.0



Where did you install the version of OpenSSL that you compiled? Did you replace the system supplied version in `/usr/lib`? If so that was probably not a good idea.







> Loaded symbols for /lib/libdl.so.2

> Loaded symbols for /lib/i686/nosegneg/libpthread.so.0

> Loaded symbols for /lib/i686/nosegneg/libc.so.6 Loaded symbols for

> /usr/lib/libkrb5support.so.0 Loaded symbols for /lib/libresolv.so.2

> Loaded symbols for /lib/libgcc_s.so.1 Loaded symbols for

> /lib/i686/nosegneg/libm.so.6 Loaded symbols for /lib/ld-linux.so.2

> 0x009e6402 in __kernel_vsyscall ()

> (gdb) c

> Continuing.

>

> Program received signal SIGSEGV, Segmentation fault.

> [Switching to Thread -1231422576 (LWP 3480)]

> 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219

> 219         if (s->renegotiate) {



There is something not quite right about that. There is no way that line should seg fault. The deref of `s` has already occurred several times by the time it gets to that line so `s` should be sound. Either there is some memory corruption going on, or that's not really the line we're on.



Matt







More information about the openssl-dev mailing list