Re: TLS/SSL Re-Negotiation Vulnerability [CVE-2011-1473]
Hi,
The following blog post explains different mitigation techniques for
this vulnerability and among them is Rate Limiting :
http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html#rate_limiting_ssl_handshakes
I hope this will help.
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 12/21/2011 7:40 PM, Hasan, Rezaul (NSN - US/Arlington Heights) wrote:
Hello All,
We have openssl 0.9.8r on our Linux Server. Application thats used is
httpd.
A Nessus security scan on our Linux server tells us that we may be
vulnerable to a potential DOS due to SSL/TLS Renegotiation
Vulnerability [CVE-2011-1473].
The suggestions of mitigating these (we believe) are:
1. Disable Re-Negotiation completely. {We CANNOT use this choice,
because our system does need to allow Re-Negotiation in some cases. So
NOT an option for us}
2. "Rate-Limit" Re-Negotiations.
Can someone please provide detailed information/guidance about exactly
how to go about "Rate-Limiting" Re-Negotiation requests on the Linux
Server? Pointing to a detailed article would also be helpful.
Thanks a bunch in advance.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Problems with including zlib
On Tue December 27 2011, Michael S. Zick wrote: > On Tue December 27 2011, Michael S. Zick wrote: > > On Tue December 27 2011, Jakob Bohm wrote: > > > On 12/26/2011 1:31 AM, Michael S. Zick wrote: > > > > On Sun December 25 2011, jb-open...@wisemo.com wrote: > > > >> Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld > > > >> specific > > > >> option to do this in manually written Makefiles. > > > >> > > > >> My replies below are about how to achieve this without GNU specific > > > >> options > > > >> and without having to edit the Configure and Makefiles. These answers > > > >> do > > > >> not apply to Windows, OS/2, DOS and other non-POSIX based build > > > >> environments. > > > >> > > > >> On 24-12-2011 05:31, grarpamp wrote: > > > 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you > > > have no > > > static zlib to link in. > > > >>> Of course there's an old libz.a there. And it should not matter as > > > >>> we're given the --with-zlib arguments to point the build elsewhere > > > >>> for those libraries. And as seen in the report, it is following those > > > >>> pointers. It's just not using them correctly regarding being told to > > > >>> link against libz.a, not libz.so, with the 'zlib' parameter to config. > > > >> If you pass Configure and option to look for zlib in an additional > > > >> directory, all of these steps apply to that directory too. > > > 2. Temporarily remove or rename the symlink named exactly "libz.so" > > > in > > > /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it > > > cannot > > > link to the dynamic zlib). > > > >>> No, this appears to be to be a ./config build parameter setup > > > >>> error. Why should user's break their perfectly sound systems > > > >>> in order to work around a bug? If users wanted it to link dynamically > > > >>> against libz, they would have specified 'zlib-dynamic' to ./config. > > > >> As partly explained by Michael, there is no portable option that > > > >> ./config could tell the Makefile to pass to the compiler/linker to > > > >> get the desired effect. It simply hasn't got a chance. > > > >> > > > >> Michael's other suggestion to first use the linker to produce and > > > >> intermediary .o file with some unresolved externals is not portable > > > >> either, as only some linkers have the ability to do that. > > > >> > > > >> However a general way to achieve this on almost any UNIX/POSIX > > > >> based system is to artificially present the linker with a scenario > > > >> where the linker thinks there is no shared library version of zlib > > > >> available, only a PIC-compiled static libz.a, which the linker will > > > >> then have to use when creating an OpenSSL shared library. > > > >> > > > >> This is achieved by temporarily hiding the libz.so -> libz.so.N > > > >> symlinks that the linker uses, but keeping the > > > >> libz.so.N -> libz.so.N.N.N symlinks used by the dynamic linker > > > >> on your working computer. > > > >> > > > > *nix base systems (the few I know of anyway) use some variation on > > > > a ld.so.* to do the dynamic linking. > > > > As part of that approach, a ld.so.cache is built on the machine with > > > > the dynamic library links pre-resolved. > > > > > > > > You can do whatever you want with the actual links on disk of a > > > > running system, just as long as you don't rebuild the ld.so.cache > > > > until they are back into working condition. > > > > > > > > As a general precaution - have the links back to their working > > > > condition before doing: make install > > > > Since the install step of some make files will force a ld.so.cache > > > > rebuild as a 'feature'. ;-) > > > > > > > > Mike > > > Thanks, I was approaching this on a more basic level: > > > > > > > I thought I was agreeing with you. ;-) > > > > My only contribution was the warning that some "make install" > > package steps might run ldconfig as part of the install. > > > > With libz from the current (1.2.5) source: > ./configure --prefix= --static > > Only builds the static archive but the makefile is broke > for installing only a static archive. (Oops) > > ./configure --perfix= > > Builds both the static and the dynamic libraries. > __BUT__ > The "make install" also gratuitously runs ldconfig with all > output directed to /dev/null so your only clue is when > your ld.so.cache turns to trash. ;-) > > That can be avoided by: > $ sudo make install LDCONFIG=false > > - - - - > > And answering my own question, why we haven't heard from > the authors - > They are waiting for one of us to read the directions. ;-) > > It reads to me as if the OpenSSL archive is already setup > to handle this situation, with: no-zlib-dynamic option. > > Will try that one myself next. > This is what I tried, with the result that the Makefile and generated opensslconf.h files looked reasonable, but... (with a bit of \ added for the m.l.:) $ ./config no-zlib-dynamic zli
Re: Problems with including zlib
On Tue December 27 2011, Michael S. Zick wrote: > On Tue December 27 2011, Jakob Bohm wrote: > > On 12/26/2011 1:31 AM, Michael S. Zick wrote: > > > On Sun December 25 2011, jb-open...@wisemo.com wrote: > > >> Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld > > >> specific > > >> option to do this in manually written Makefiles. > > >> > > >> My replies below are about how to achieve this without GNU specific > > >> options > > >> and without having to edit the Configure and Makefiles. These answers do > > >> not apply to Windows, OS/2, DOS and other non-POSIX based build > > >> environments. > > >> > > >> On 24-12-2011 05:31, grarpamp wrote: > > 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you have > > no > > static zlib to link in. > > >>> Of course there's an old libz.a there. And it should not matter as > > >>> we're given the --with-zlib arguments to point the build elsewhere > > >>> for those libraries. And as seen in the report, it is following those > > >>> pointers. It's just not using them correctly regarding being told to > > >>> link against libz.a, not libz.so, with the 'zlib' parameter to config. > > >> If you pass Configure and option to look for zlib in an additional > > >> directory, all of these steps apply to that directory too. > > 2. Temporarily remove or rename the symlink named exactly "libz.so" in > > /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it cannot > > link to the dynamic zlib). > > >>> No, this appears to be to be a ./config build parameter setup > > >>> error. Why should user's break their perfectly sound systems > > >>> in order to work around a bug? If users wanted it to link dynamically > > >>> against libz, they would have specified 'zlib-dynamic' to ./config. > > >> As partly explained by Michael, there is no portable option that > > >> ./config could tell the Makefile to pass to the compiler/linker to > > >> get the desired effect. It simply hasn't got a chance. > > >> > > >> Michael's other suggestion to first use the linker to produce and > > >> intermediary .o file with some unresolved externals is not portable > > >> either, as only some linkers have the ability to do that. > > >> > > >> However a general way to achieve this on almost any UNIX/POSIX > > >> based system is to artificially present the linker with a scenario > > >> where the linker thinks there is no shared library version of zlib > > >> available, only a PIC-compiled static libz.a, which the linker will > > >> then have to use when creating an OpenSSL shared library. > > >> > > >> This is achieved by temporarily hiding the libz.so -> libz.so.N > > >> symlinks that the linker uses, but keeping the > > >> libz.so.N -> libz.so.N.N.N symlinks used by the dynamic linker > > >> on your working computer. > > >> > > > *nix base systems (the few I know of anyway) use some variation on > > > a ld.so.* to do the dynamic linking. > > > As part of that approach, a ld.so.cache is built on the machine with > > > the dynamic library links pre-resolved. > > > > > > You can do whatever you want with the actual links on disk of a > > > running system, just as long as you don't rebuild the ld.so.cache > > > until they are back into working condition. > > > > > > As a general precaution - have the links back to their working > > > condition before doing: make install > > > Since the install step of some make files will force a ld.so.cache > > > rebuild as a 'feature'. ;-) > > > > > > Mike > > Thanks, I was approaching this on a more basic level: > > > > I thought I was agreeing with you. ;-) > > My only contribution was the warning that some "make install" > package steps might run ldconfig as part of the install. > With libz from the current (1.2.5) source: ./configure --prefix= --static Only builds the static archive but the makefile is broke for installing only a static archive. (Oops) ./configure --perfix= Builds both the static and the dynamic libraries. __BUT__ The "make install" also gratuitously runs ldconfig with all output directed to /dev/null so your only clue is when your ld.so.cache turns to trash. ;-) That can be avoided by: $ sudo make install LDCONFIG=false - - - - And answering my own question, why we haven't heard from the authors - They are waiting for one of us to read the directions. ;-) It reads to me as if the OpenSSL archive is already setup to handle this situation, with: no-zlib-dynamic option. Will try that one myself next. Mike > > Dynamic linking __only__ reads ld.so.cache, so as long as > nothing (or no one) runs ldconfig - do as you wish with the links. > > > On the systems I know about (not many, sorry), ld.so.* and its caching > > system > > looks at the symlinks from libz.so.N to libz.so.N.N.N, which is why > > those symlinks > > tend to be included in the "runtime" shared library install packages for > > the system. > > > > While /usr/bin/ld (etc.) looks at the libz.so to li
Re: Problems with including zlib
On Tue December 27 2011, Jakob Bohm wrote: > On 12/26/2011 1:31 AM, Michael S. Zick wrote: > > On Sun December 25 2011, jb-open...@wisemo.com wrote: > >> Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld > >> specific > >> option to do this in manually written Makefiles. > >> > >> My replies below are about how to achieve this without GNU specific options > >> and without having to edit the Configure and Makefiles. These answers do > >> not apply to Windows, OS/2, DOS and other non-POSIX based build > >> environments. > >> > >> On 24-12-2011 05:31, grarpamp wrote: > 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you have no > static zlib to link in. > >>> Of course there's an old libz.a there. And it should not matter as > >>> we're given the --with-zlib arguments to point the build elsewhere > >>> for those libraries. And as seen in the report, it is following those > >>> pointers. It's just not using them correctly regarding being told to > >>> link against libz.a, not libz.so, with the 'zlib' parameter to config. > >> If you pass Configure and option to look for zlib in an additional > >> directory, all of these steps apply to that directory too. > 2. Temporarily remove or rename the symlink named exactly "libz.so" in > /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it cannot > link to the dynamic zlib). > >>> No, this appears to be to be a ./config build parameter setup > >>> error. Why should user's break their perfectly sound systems > >>> in order to work around a bug? If users wanted it to link dynamically > >>> against libz, they would have specified 'zlib-dynamic' to ./config. > >> As partly explained by Michael, there is no portable option that > >> ./config could tell the Makefile to pass to the compiler/linker to > >> get the desired effect. It simply hasn't got a chance. > >> > >> Michael's other suggestion to first use the linker to produce and > >> intermediary .o file with some unresolved externals is not portable > >> either, as only some linkers have the ability to do that. > >> > >> However a general way to achieve this on almost any UNIX/POSIX > >> based system is to artificially present the linker with a scenario > >> where the linker thinks there is no shared library version of zlib > >> available, only a PIC-compiled static libz.a, which the linker will > >> then have to use when creating an OpenSSL shared library. > >> > >> This is achieved by temporarily hiding the libz.so -> libz.so.N > >> symlinks that the linker uses, but keeping the > >> libz.so.N -> libz.so.N.N.N symlinks used by the dynamic linker > >> on your working computer. > >> > > *nix base systems (the few I know of anyway) use some variation on > > a ld.so.* to do the dynamic linking. > > As part of that approach, a ld.so.cache is built on the machine with > > the dynamic library links pre-resolved. > > > > You can do whatever you want with the actual links on disk of a > > running system, just as long as you don't rebuild the ld.so.cache > > until they are back into working condition. > > > > As a general precaution - have the links back to their working > > condition before doing: make install > > Since the install step of some make files will force a ld.so.cache > > rebuild as a 'feature'. ;-) > > > > Mike > Thanks, I was approaching this on a more basic level: > I thought I was agreeing with you. ;-) My only contribution was the warning that some "make install" package steps might run ldconfig as part of the install. Dynamic linking __only__ reads ld.so.cache, so as long as nothing (or no one) runs ldconfig - do as you wish with the links. > On the systems I know about (not many, sorry), ld.so.* and its caching > system > looks at the symlinks from libz.so.N to libz.so.N.N.N, which is why > those symlinks > tend to be included in the "runtime" shared library install packages for > the system. > > While /usr/bin/ld (etc.) looks at the libz.so to libz.so.N symlinks to > decide which > libz.* to link to when the command line says "-lz", which is why those > symlinks tend to be included in the "development" library install packages. > Ah, another point I was not clear on: --start-group libz.a --end-group not use the (also allowed): --start-group -lz --end-group The manual only says: "explicit file name(s)" so that might allow full pathnames also. The OP's question was: "How to get OpenSSL build to do this?" I have not looked at the Makefile myself, I thought one of the Makefile authors would post to this thread. Maybe it already recognizes a: --libz-static option. Mike > >> __ > >> OpenSSL Project http://www.openssl.org > >> User Support Mailing Listopenssl-users@openssl.org > >> Automated List Manager majord...@openssl.org > >> > >> > > _
Re: Supporting oldwithold, newwithnew CA certificates Reg.
Sorry for spamming, a small correction here. Scenario 3 is also failing and not successful as indicated in my earlier email. *Scenario 3:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection failure. Regds, Ashok On Tue, Dec 27, 2011 at 4:50 PM, Ashok C wrote: > Thanks Dave. > But regarding this: > > >>Important note: make sure the old and new root certs have different > names. (Same for intermediate CAs, which your example doesn't have.) > OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, > and of course uses subjectkey to verify child and thus gets an error > if lookup found wrong parent. But it looks-up only by name, so if > old and new certs have the same name OpenSSL may use the wrong one. > >> > > > I actually tested this particular scenario in my testbed and found that it > is not necessary that the old and new CA certs have different names. > I generated an oldcacert.pem and and oldcakey.pem using which I signed my > oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem > using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem > had the same subject/issuer names. The scenarios I tested go below: > *Scenario 1:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem > Result: Connection successful > > *Scenario 2:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/newcacert.pem > Result:Connection successful > > *Scenario 3:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem > Result: Connection successful > * > Scenario 4:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/newcacert.pem > Result: Connection Failure > > Now, I put both oldcacert.pem and newcacert.pem into a single > combined.pem, the first certificate being oldcacert.pem and the second > certificate being newcacert.pem. > > *Scenario 5:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/combined.pem > Result: Connection Successful > > *Scenario 6:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/combined.pem > Result: Connection Successful > > So now, this means that the openSSL verification check does not stop with > the first matching issuer certificate alone right? Because if that was the > case, Scenario 6 should have failed. > I have attached my certificates for reference. All are v3 certificates. > I am using openssl version "openssl-0.9.8g". > > One more clarification: > > >>If OpenSSL client has cert-and-pkey configured and receives CertReq, > it sends that cert regardless of any CAlist the server asked for; > that cert may be accepted or not depending on the server. And if > callback or engine is used it appears (but I haven't tested) that > can similarly select any cert regardless of what the server asked. > >> > > > Are you indicating here that the client can have multiple end entity > certificates? Till now I had the assumption that the server/client can have > only a single end entity certificate. Also, if the server can ask client to > send selective certificates, wouldn't it be applicable that the client also > can request the server for specific certificates? Are there separate > openSSL APIs for this or we have to use the same family of > ssl_ctx_set_client* family of APIs for this purpose also? > > Regds, > Ashok > > > > > > > > On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson wrote: > >> > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C >> > Sent: Thursday, 22 December, 2011 10:55 >> >> > Another doubt I have is about the SSL_CTX_set_client_ca_list >> > and the SSL_get_client_ca_list. >> >> > I understand that the set method is called by the server to >> > set the list of CA names that it actually expects from the client. >> > And the client calls ssl_get_client_ca_list to get these names and >> > send the appropriate CA certificates in its chain for verification >> > to the server. >> >> Nit: case is important in C identifiers. Skipping that: >> >> Not quite. Server can call _set_client_CA_list to set the CA names it >> *asks for* from the client; server still uses _load_verify_locations >> to verify the cert received if any. OpenSSL allows you to make these >> different: e.g. ask the client for CA1 and CA2, but verify only CA2, >> or CA2 and CA3, or only CA3. I've never seen a good use for this. >> >> OpenSSL client calls the client_cert callback or engine only if >> you did *not* set a cert-and-private-key before the handshake. >> Callback or engine can look at the CAlist specified by the server >> if any (see next) to choose what cert-a
Re: Supporting oldwithold, newwithnew CA certificates Reg.
Thanks Dave. But regarding this: >>Important note: make sure the old and new root certs have different names. (Same for intermediate CAs, which your example doesn't have.) OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, and of course uses subjectkey to verify child and thus gets an error if lookup found wrong parent. But it looks-up only by name, so if old and new certs have the same name OpenSSL may use the wrong one. >> I actually tested this particular scenario in my testbed and found that it is not necessary that the old and new CA certs have different names. I generated an oldcacert.pem and and oldcakey.pem using which I signed my oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem had the same subject/issuer names. The scenarios I tested go below: *Scenario 1:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection successful *Scenario 2:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/newcacert.pem Result:Connection successful *Scenario 3:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection successful * Scenario 4:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/newcacert.pem Result: Connection Failure Now, I put both oldcacert.pem and newcacert.pem into a single combined.pem, the first certificate being oldcacert.pem and the second certificate being newcacert.pem. *Scenario 5:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/combined.pem Result: Connection Successful *Scenario 6:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/combined.pem Result: Connection Successful So now, this means that the openSSL verification check does not stop with the first matching issuer certificate alone right? Because if that was the case, Scenario 6 should have failed. I have attached my certificates for reference. All are v3 certificates. I am using openssl version "openssl-0.9.8g". One more clarification: >>If OpenSSL client has cert-and-pkey configured and receives CertReq, it sends that cert regardless of any CAlist the server asked for; that cert may be accepted or not depending on the server. And if callback or engine is used it appears (but I haven't tested) that can similarly select any cert regardless of what the server asked. >> Are you indicating here that the client can have multiple end entity certificates? Till now I had the assumption that the server/client can have only a single end entity certificate. Also, if the server can ask client to send selective certificates, wouldn't it be applicable that the client also can request the server for specific certificates? Are there separate openSSL APIs for this or we have to use the same family of ssl_ctx_set_client* family of APIs for this purpose also? Regds, Ashok On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Thursday, 22 December, 2011 10:55 > > > Another doubt I have is about the SSL_CTX_set_client_ca_list > > and the SSL_get_client_ca_list. > > > I understand that the set method is called by the server to > > set the list of CA names that it actually expects from the client. > > And the client calls ssl_get_client_ca_list to get these names and > > send the appropriate CA certificates in its chain for verification > > to the server. > > Nit: case is important in C identifiers. Skipping that: > > Not quite. Server can call _set_client_CA_list to set the CA names it > *asks for* from the client; server still uses _load_verify_locations > to verify the cert received if any. OpenSSL allows you to make these > different: e.g. ask the client for CA1 and CA2, but verify only CA2, > or CA2 and CA3, or only CA3. I've never seen a good use for this. > > OpenSSL client calls the client_cert callback or engine only if > you did *not* set a cert-and-private-key before the handshake. > Callback or engine can look at the CAlist specified by the server > if any (see next) to choose what cert-and-private-key to use. > For callback it apparently needs to call SSL_get_client_CA_list, > for engine this value is passed separately. > > > I assume that both these methods are actually optional even when > SSL_VERIFY_PEER > > flag is set to true, i.e., client verifies server and server > verifies client. > > If OpenSSL server sets VERIFY_PEER but doesn't _set_client_CA_list, > it sends CertReq with an empty CA list. According to the RFCs > in this case "the client MAY send any certificate of the appropriate > Clie
observing a crash while doing ssl_connect
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: Problems with including zlib
On 12/26/2011 1:31 AM, Michael S. Zick wrote: On Sun December 25 2011, jb-open...@wisemo.com wrote: Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld specific option to do this in manually written Makefiles. My replies below are about how to achieve this without GNU specific options and without having to edit the Configure and Makefiles. These answers do not apply to Windows, OS/2, DOS and other non-POSIX based build environments. On 24-12-2011 05:31, grarpamp wrote: 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you have no static zlib to link in. Of course there's an old libz.a there. And it should not matter as we're given the --with-zlib arguments to point the build elsewhere for those libraries. And as seen in the report, it is following those pointers. It's just not using them correctly regarding being told to link against libz.a, not libz.so, with the 'zlib' parameter to config. If you pass Configure and option to look for zlib in an additional directory, all of these steps apply to that directory too. 2. Temporarily remove or rename the symlink named exactly "libz.so" in /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it cannot link to the dynamic zlib). No, this appears to be to be a ./config build parameter setup error. Why should user's break their perfectly sound systems in order to work around a bug? If users wanted it to link dynamically against libz, they would have specified 'zlib-dynamic' to ./config. As partly explained by Michael, there is no portable option that ./config could tell the Makefile to pass to the compiler/linker to get the desired effect. It simply hasn't got a chance. Michael's other suggestion to first use the linker to produce and intermediary .o file with some unresolved externals is not portable either, as only some linkers have the ability to do that. However a general way to achieve this on almost any UNIX/POSIX based system is to artificially present the linker with a scenario where the linker thinks there is no shared library version of zlib available, only a PIC-compiled static libz.a, which the linker will then have to use when creating an OpenSSL shared library. This is achieved by temporarily hiding the libz.so -> libz.so.N symlinks that the linker uses, but keeping the libz.so.N -> libz.so.N.N.N symlinks used by the dynamic linker on your working computer. *nix base systems (the few I know of anyway) use some variation on a ld.so.* to do the dynamic linking. As part of that approach, a ld.so.cache is built on the machine with the dynamic library links pre-resolved. You can do whatever you want with the actual links on disk of a running system, just as long as you don't rebuild the ld.so.cache until they are back into working condition. As a general precaution - have the links back to their working condition before doing: make install Since the install step of some make files will force a ld.so.cache rebuild as a 'feature'. ;-) Mike Thanks, I was approaching this on a more basic level: On the systems I know about (not many, sorry), ld.so.* and its caching system looks at the symlinks from libz.so.N to libz.so.N.N.N, which is why those symlinks tend to be included in the "runtime" shared library install packages for the system. While /usr/bin/ld (etc.) looks at the libz.so to libz.so.N symlinks to decide which libz.* to link to when the command line says "-lz", which is why those symlinks tend to be included in the "development" library install packages. __ 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
