observing a crash while doing ssl_connect on linux 5.5 platform

2012-01-02 Thread Patil, Minal
Hello Sir/Madam,

I am seeing a crash while authenticating through open ldap on linux 5.5 x86-64. 
The application is 32 bit multithreaded.
I am using openssl0.9.8e version.

Below is  stack trace for same
*** glibc detected *** ./cserver: free(): invalid pointer: 0xf47fa858 ***
=== Backtrace: =
/lib/libc.so.6[0xb325a5]
/lib/libc.so.6(cfree+0x59)[0xb329e9]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(CRYPTO_free+0x2d)[0xf7ad7f7e]
/lib/libssl.so.6(ssl3_connect+0x852)[0xf6ddda32]
/lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a]
/lib/libssl.so.6(ssl23_connect+0xb01)[0xf6de4431]
/lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a]
/usr/lib/libldap-2.3.so.0(ldap_int_tls_start+0xac)[0xf6e6098c]
/usr/lib/libldap-2.3.so.0(ldap_int_open_connection+0x1a0)[0xf6e3cce0]
/usr/lib/libldap-2.3.so.0(ldap_new_connection+0xa6)[0xf6e506a6]
/usr/lib/libldap-2.3.so.0(ldap_open_defconn+0x41)[0xf6e3cb11]
/usr/lib/libldap-2.3.so.0(ldap_send_initial_request+0xd8)[0xf6e510b8]
/usr/lib/libldap-2.3.so.0(ldap_sasl_bind+0x178)[0xf6e461d8]
/usr/lib/libldap-2.3.so.0(ldap_simple_bind+0x8a)[0xf6e4675a]
/lib/security/pam_ldap.so[0xf6e7bd4d]
/lib/security/pam_ldap.so[0xf6e7c619]
/lib/security/pam_ldap.so[0xf6e7df59]
/lib/security/pam_ldap.so(pam_sm_authenticate+0x2f0)[0xf6e7e260]
/lib/libpam.so.0(_pam_dispatch+0x28f)[0xf78c843f]
/lib/libpam.so.0(pam_authenticate+0x51)[0xf78c7c81]
/opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so[0xf6ed35c7]
/opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so(BAA_ImportLoginUser+0x100)[0xf6ed470a]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(BAA_LoginUser+0x21)[0xf7b3c9a0]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject13checkPasswordEP11BAA_SESSIONRK11I18n_StringRK11bmc_string8+0x65)[0xf7ace8b9]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PP11OSS_Account+0x8c)[0xf7ace5e4]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN14OSS_AuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PK14OSS_EncryptionPP11OSS_AccountR9OSS_Error+0xbc)[0xf7a84e48]
/opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0[0xf7df6ca0]
/opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0(_ZN19Agent_MLMChallenger17checkPasswordAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK11bmc_string8P22Cpl_AuthSchemeCallbackRS3_Rb+0x6c)[0xf7df9118]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN23Auth_PasswordChallenger18handleResponseAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_jRK15Cpl_AuthArgListRS6_RS3_P22Cpl_AuthSchemeCallbackRb+0xdb)[0xf7d739b7]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme20dispatchResponseAsynERK11bmc_string8RP16Cpl_AuthUserDataRK12bmc_string16S8_S8_jRK15Cpl_AuthArgListRS9_RS6_P22Cpl_AuthSchemeCallbackRb+0x61)[0xf7d76859]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme19handleResponseAsyncERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK15Cpl_AuthArgListP22Cpl_AuthSchemeCallback+0x1f6)[0xf7d7662e]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_AuthServer12authenticateER14Cos_IPCMessageR11I18n_String+0x48c)[0xf7c51094]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject24_handleRPCRequestMessageER14Cos_IPCMessageb+0x2fac)[0xf7ca19a8]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject17_decodeCosMessageER14Cos_IPCMessage+0x94)[0xf7ca339c]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_IPCMessage7executeEv+0x22)[0xf7c655aa]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN15OSS_Gen_ThreadQ15dispatchMessageEP11OSS_Message+0x29)[0xf7ac9539]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN21_Cos_ThreadPoolMember10threadProcEv+0x6a)[0xf7c43a2a]
/opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libtss_t.so.9[0xf7db9fdf]
/lib/libpthread.so.0[0xc28832]
/lib/libc.so.6(clone+0x5e)[0xb9ae0e]

Please suggest how we can proceed with the same. Above stack trace shows the 
CRYPTO_free function is from liboss_t.so but there is no such function in the 
library. While building the same it was linked with openssl library.

Please suggest how should we diagnose the problem further.

Thanks,
Minal




Re: how to see the SSL handshake

2012-01-02 Thread tq jia
Hello, You can use the tool -SSLdump to get the SSL handshake tracing!
Thanks

2011/12/28 Mithun Kumar mithunsi...@gmail.com

 Hello Forum,

 I am currently running the samples(client1,server1) , is there any
 environmental variables that i need to export so that i can get the SSL
 handshake tracing?

 -Thanks
  mithun



Re: Problems with including zlib

2012-01-02 Thread Michael S. Zick
On Sun January 1 2012, grarpamp wrote:
  Translation: I have to agree with O.P. - It looks broke to me too.  ;-)
 
 Heh, that's precisely what I said in my report :) The front end
 options to do it seem to exist, and they even have some brief
 descriptions as such.  They just don't work :)
 
 'zlib' should get us static inclusion.


There is an inconsistency in the output of ./config --help, the
documentation, and what is written in the config/make code.

The true meaning (as executed) is:
zlib / no-zlib (no-zlib is the default) controls the presence
of compression (except for a source file or two that isn't
properly conditioned to match that).

IF compressed streams are enabled, then:
no-zlib-dynamic (the default) should get you the compression 
statically included.

 'zlib-dynamic' should get us dynamic inclusion.


And that should get you a reference to the specified dynamic library.
But the build system is always referring to the system installed libraries.

Which is why I showed in my example the use of a library other
than the system installed one.

The real key here is to ignore the --help and the documentation
and read the top Makefile __before__ running the config step(s).
 
 And then there's the failure of zlib to actually compress the data
 before encryption, also in my report. (gmail stupidly wrapped the
 command lines on that, sorry.)


I was able to get the compression test to fail/pass depending on
how I (mis-)configured/built the package. 

But I didn't check if compression is used outside of make test.
;-)

 I'll play around with the build system. And file a bug. Hopefully
 something will follow.
 
 Ps: The -D options are not needed since the --with versions of them
 work fine. Again, as in my report.


I didn't check the --with versions, only found that the -D options are
being ignored although passed with the commands., maybe the --with 
versions do work.
Which doesn't mean that the -D options are not also broke.  ;-)

Also, gcc option parsing is becoming more strict.
At the moment (v4.6) it only warns that link options are being passed
when no linking is being done.

I just am not comfortable enough with that perlized makefile build
system to even guess at where that needs to be fixed before a newer
gcc version turns that warning into a failure.

Mike
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org