Bug 111492 - [PATCH] LDAP clients segfault with subjectAltName entries in TLS cert
[PATCH] LDAP clients segfault with subjectAltName entries in TLS cert
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openldap (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 112275 126973 128364 (view as bug list)
Depends On:
Blocks: 116727
  Show dependency treegraph
 
Reported: 2003-12-04 10:29 EST by Jared Cook
Modified: 2010-04-08 04:11 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-18 23:23:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to resolve problem (916 bytes, patch)
2004-02-23 12:16 EST, Aaron Spangler
no flags Details | Diff
Patch related to OpenLDAP ext_free bug (697 bytes, patch)
2004-08-17 03:43 EDT, Tarun Bhushan
no flags Details | Diff

  None (edit)
Description Jared Cook 2003-12-04 10:29:25 EST
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:
Comment 1 Mike Austin 2003-12-04 20:24:33 EST
We're having the exact same problem.  Is there a resolution?
Comment 2 David Shafer 2003-12-05 11:54:59 EST
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)
Comment 3 David Shafer 2003-12-05 11:58:56 EST
It appears this may be related to bug #85728 (for RH 9), which 
already contains extensive debugging info.
Comment 4 Jason Heiss 2004-01-22 16:03:40 EST
*** Bug 112275 has been marked as a duplicate of this bug. ***
Comment 5 Aaron Spangler 2004-02-23 12:16:37 EST
Created attachment 97953 [details]
Patch to resolve problem

Patch to resolve LDAP + SSL + AltSubject Bug
Comment 6 Aaron Spangler 2004-02-23 12:17:17 EST
I submitted a patch
Comment 7 Aaron Spangler 2004-02-23 12:55:46 EST
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
Comment 8 David Shafer 2004-04-16 18:09:58 EDT
I've confirmed the patch corrects the problem I was encountering.
Comment 10 Nalin Dahyabhai 2004-05-18 14:55:54 EDT
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.
Comment 11 Aaron Spangler 2004-05-27 14:44:02 EDT
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
Comment 12 Nalin Dahyabhai 2004-05-27 17:40:42 EDT
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.
Comment 13 Kevin W. Rudd 2004-06-08 13:47:32 EDT
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

Comment 15 Don Howard 2004-07-07 11:21:46 EDT
Nalin, 
 
openldap-2.0.27-14 appears to be set for u3.   
Can you confirm that it will be included? 
Comment 17 David Mahder 2004-08-16 16:05:54 EDT
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
Comment 18 Tarun Bhushan 2004-08-17 03:43:04 EDT
Created attachment 102781 [details]
Patch related to OpenLDAP ext_free bug
Comment 19 Tarun Bhushan 2004-08-17 03:44:29 EDT
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.
Comment 20 Thomas Woerner 2004-08-17 04:55:57 EDT
*** Bug 128364 has been marked as a duplicate of this bug. ***
Comment 21 Jay Turner 2004-08-17 10:33:07 EDT
Can I get confirmation from users that the 2.0.27-14 package is
resolving the issues you are seeing?
Comment 22 David Shafer 2004-08-17 16:12:16 EDT
I've confirmed that 2.0.27-14 resolves my problem.
Comment 23 Jay Turner 2004-08-18 23:23:24 EDT
Closing out based on confirmation from original reporter.
Comment 24 Tarun Bhushan 2004-08-18 23:41:29 EDT
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
Comment 25 Nalin Dahyabhai 2004-08-20 21:18:14 EDT
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.
Comment 26 Jay Turner 2004-09-01 22:15:18 EDT
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
Comment 27 Jay Turner 2004-09-02 19:35:29 EDT
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
Comment 28 Jan Zeleny 2010-04-08 04:11:15 EDT
*** Bug 126973 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.