Thanks Stephen for your reply. I am doing "OpenSSL_add_all_digests" in one of my class initialization routine, so it gets called whenever an instance of this class gets created (I am now building my code with this removed). But I am not removing digests/algorithm as you mention, I am just adding them. Can it still be the reason for this race ?
Thanks. -Arun On Thu, Aug 7, 2014 at 4:16 PM, Dr. Stephen Henson <[email protected]> wrote: > On Wed, Aug 06, 2014, arun11299 wrote: > >> Hello Folks, >> I am experiencing a hard to debug crash in openssl crypto library within our >> process. >> We have a client and server which communicates using SSL with NULL >> encryption. The client when it connects to the server sends a Certificate >> signing request, the server responds by sending the server certificate. All >> works fine during test and even under load using openssl version 0.9.8 and >> also 1.0.1f I believe, but we are experiencing crash with version 1.0.1h >> under load setup (Once every day). >> >> The simulator which we use to simulate a client disconnects and connects >> back to the server many times, each time asking for the certificate from the >> server. The crash was seen just once the entire day. So I dont think its >> anywhere close to broken functionality. Looks like more of a race issue. >> >> Similar references: >> http://openssl.6102.n7.nabble.com/Crash-in-libcrypto-so-1-0-0-td42043.html >> >> Also, I have verified the data sent by the client from the core dump using a >> test program. >> Also from openssl command: >> openssl req -inform DER -in filebin -verify >> verify OK >> ....... >> .... >> .... >> >> So it is not that the client is sending corrupt data, even if it was >> sending, it should have failed in "d2i_X509_REQ" which we call before >> calling "X509_REQ_verify". >> >> This is the stack trace we get (Top half only): >> >> Thread 1 (Thread 0x7fa62851d700 (LWP 19528)): >> #0 0x00007fa62657f2d6 in __strcmp_sse42 () from /lib64/libc.so.6 >> #1 0x00007fa6276f5b4a in ?? () from /usr/lib64/libcrypto.so.10 >> #2 0x00007fa6276f5b8c in lh_retrieve () from /usr/lib64/libcrypto.so.10 >> #3 0x00007fa62767c758 in OBJ_NAME_get () from /usr/lib64/libcrypto.so.10 >> #4 0x00007fa62770d49d in ASN1_item_verify () from >> /usr/lib64/libcrypto.so.10 >> #5 0x00000000008a1fd7 in ca::CA::process_cert_request(unsigned char const*, >> unsigned long, std::vector<unsigned char, std::allocator<unsigned char> >*) >> () >> > > It's hard to tell from that description but it could be a race condition > relating to algorithm tables. That might happen if you add all algorithms and > remove them on every invocation of a function instead of adding them just once > on application startup. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
