Description of problem: openldap client tools segfault while using TLS if x509 cert contains `subjectAltName=DNS:hostname.com`. subjectAltNames are necessary to use TLS for replication within a load-blanaced TLS secure LDAP implementaion. Version-Release number of selected component (if applicable): openldap-clients-2.0.27-11 How reproducible: use a cert with a subjectAltName= entry, and do an ldap search with TLS. Steps to Reproduce: 1.create a cert with a subjectAltName=DNS:hostname entry 2.restart LDAP using that cert. 3.ldapsearch -x -H ldap://example.com -ZZ -s base Actual results: segementation fault Expected results: results from LDAP database Additional info:
We're having the exact same problem. Is there a resolution?
We are also experiencing the same problem with RHEL 3. Here is debug output from ldapsearch: $ ldapsearch -h ldaphost -W -x -ZZ -d 1 ... TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A ... TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A Segmentation fault (core dumped)
It appears this may be related to bug #85728 (for RH 9), which already contains extensive debugging info.
*** Bug 112275 has been marked as a duplicate of this bug. ***
Created attachment 97953 [details] Patch to resolve problem Patch to resolve LDAP + SSL + AltSubject Bug
I submitted a patch
Here is a stack trace. I had to build this by hande using ddd one instruction at a time. The problem is that the offending code calls a null pointer and corrupts the stack, so a simple 'bt' cannot be automatically generated. Stack trace of /usr/bin/ldapsearch main() ldap_simple_bind_s() ldap_sasl_bind_s() ldap_sasl_bind_s() ldap_send_initial_request() ldap_open_defconn() ldap_new_connection() ldap_int_open_connection() ldap_int_tls_start() ldap_pvt_tls_check_hostname() tls.c line 844: method=X509V3_EXT_get(ex); tls.c line 845: method->ext_free(alt); <kills the stack> The structure member method->ext_free=0 before calling
I've confirmed the patch corrects the problem I was encountering.
Turns out this was an unexpected API change between OpenSSL 0.9.6 and 0.9.7, so it had to be conditionalized on that for the SRPM because we use the same SRPM for both RHEL 2.1 and 3.0 (though this problem doesn't affect RHEL 2.1 because the code as-shipped is right for the version of OpenSSL included with RHEL 2.1). That last hunk at the end reverts an upstream change which was labelled as a bug fix, so for the moment at least I've dropped it. The rest should show up in 2.0.27-13.
Hi Nalin, Please add in that 'last hunk at the end' that you for the moment dropped. Both parts are absolutely necessary for us! If the second half of the patch does not get applied, then there still is a significant bug of using LDAP with TLS. OpenLDAP fixed their code over a year ago (Oct 2002 if I remember). The bug is like this: Even if the program specifically requests the OpenLDAP libraries to turn off certificate checking, all the checks are turned off except the hostname check. For some reason, they forgot to make the logic right when they coded 2.0. At the time of the patch, they told me they only can fix 2.1, so they only patched 2.1. We already have 550 servers at our client site in production that have the patched version of OpenLDAP 2.0. Since OpenLDAP fixed the bug I assumed that RedHat would also apply the patch in a reasonable ammount of time. Please see the following OpenLDAP ITS report for more details: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2161 It would be really disappointing if RedHat was unable to patch OpenLDAP with an OpenLDAP patch that went well over a year ago. Please reconsider adding the second half of the patch since other major vendors (Sun, HP, IBM, Suse) already ship with the correct behaviour. -Aaron
Looking at it again, I've become convinced you're right. Checking the host name only makes sense if the certificate is also being cryptographically verified, otherwise it just provides an illusion of increased security. Revising.
There is an additional LDAP bug that needs to be addressed. Please see the following OpenLDAP bug report for details: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1924
Nalin, openldap-2.0.27-14 appears to be set for u3. Can you confirm that it will be included?
Nalin, re: comments 11 & 12, what timeframe do you expect the fix to be released, is it possible to get srpm for this or will it be included in update 3 ? thanks, dave mahder
Created attachment 102781 [details] Patch related to OpenLDAP ext_free bug
Bug 128364, entered against FreeRadius for RHEL3, is actually due to this issue. I found OpenLDAP bug 1924 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1924;selectid=1924) and applied it to OpenLDAP 2.0.27-11, with appropriate line changes as shown below, and was able to get FreeRadius working with LDAP & TLS. I hope this patch will be applied to the next OpenLDAP update (u3?). Patch is attached.
*** Bug 128364 has been marked as a duplicate of this bug. ***
Can I get confirmation from users that the 2.0.27-14 package is resolving the issues you are seeing?
I've confirmed that 2.0.27-14 resolves my problem.
Closing out based on confirmation from original reporter.
I just tried 2.0.27-14 too, and do not face the issue I was seeing. So that way the problem is fixed. Just a comment, though. The library files on /usr/lib still show the version number as 2.0.17. For example: ls -l /usr/lib/libldap*so* lrwxrwxrwx 1 root root 19 Aug 20 19:02 /usr/lib/libldap_r.so -> libldap_r.so.2.0.17 lrwxrwxrwx 1 root root 19 Aug 20 19:01 /usr/lib/libldap_r.so.2 -> libldap_r.so.2.0.17 -rwxr-xr-x 1 root root 183336 Aug 20 18:26 /usr/lib/libldap_r.so.2.0.17 lrwxrwxrwx 1 root root 17 Aug 20 19:02 /usr/lib/libldap.so -> libldap.so.2.0.17 lrwxrwxrwx 1 root root 17 Aug 20 19:01 /usr/lib/libldap.so.2 -> libldap.so.2.0.17 -rwxr-xr-x 1 root root 172496 Aug 20 18:26 /usr/lib/libldap.so.2.0.17
The version number of the shared library doesn't necessarily reflect the version number of the software package to which it belongs. Such a correlation is usually the exception rather than the rule because the version number of the shared library is not intended for human consumption. The shared library's version number should be changed exclusively to mark changes in the binary interface provided by that library.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-224.html
*** Bug 126973 has been marked as a duplicate of this bug. ***