Bug 85728 - ldapsearch segfaults with -ZZ (tls option) pam auth ldap fails with TLS on
ldapsearch segfaults with -ZZ (tls option) pam auth ldap fails with TLS on
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: openldap (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Jay Turner
:
: 107145 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-06 11:57 EST by Need Real Name
Modified: 2015-01-07 19:04 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 13:34:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
debug file for redhat-ldapsearch (13.51 KB, text/plain)
2003-03-06 12:15 EST, Need Real Name
no flags Details
debug output from source compile - no segfault (17.63 KB, text/plain)
2003-03-06 12:17 EST, Need Real Name
no flags Details
ldd output for the two different versions of ldapsearch (1.92 KB, text/plain)
2003-03-06 12:17 EST, Need Real Name
no flags Details
backport of 2.1.22 ldap_pvt_check_hostname (9.86 KB, patch)
2003-08-22 04:33 EDT, Neil Dunbar
no flags Details | Diff
strace of login process which segfaults (1.73 KB, text/plain)
2004-03-09 21:50 EST, Steven Seed
no flags Details

  None (edit)
Description Need Real Name 2003-03-06 11:57:40 EST
Description of problem:
On a clean Phoebe install any TLS or SSL enabled communication with an LDAP
server (multiple platforms/versions) fails. a straightforward ldapsearch, ie:

  ldapsearch -LLL -x -h ldaphost "(sn=smith)" cn 

succeeds and returns whereas a TLS connection

  ldapsearch -LLL -x -ZZ -h ldaphost "(sn=smith)" cn

segfaults. Authentication using TLS always fails. An ldapsearch from a rebuild
of the srpm always segfaults but a build of the source tarball (openldap-2.1.14)
succeeds - although you have to simlink several kerberos header files from
/usr/kerberos/include into /usr/include/openssl or edit /usr/include/openssl/ssl.h

Version-Release number of selected component (if applicable):
openldap-2.0.27-8
openldap-clients-2.0.27-8

How reproducible:
ldap search with -ZZ option or enable TLS in /etc/ldap.conf 


Steps to Reproduce:
1. ldapsearch -LLL -x -ZZ -h ldaphost "(sn=smith)" cn
2.  thats it
3.
    
Actual results:
Segmentation fault (trace follows)

Expected results:
dn: cn=jackal,ou=people,dc=dcs,dc=qmul,dc=ac,dc=uk
cn: Alexander Smith
sn: Smith
telephoneNumber:: IA==
 
dn: cn=rts1,ou=people,dc=dcs,dc=qmul,dc=ac,dc=uk
cn: Richard Smith
sn: Smith
telephoneNumber:: IA==


Additional info:
This is using openssl-(devel)-0.9.7-6
Comment 1 Need Real Name 2003-03-06 12:15:48 EST
Created attachment 90493 [details]
debug file for redhat-ldapsearch

command line =	ldapsearch -d -1 -LLL -x -ZZ -h vicar \"\(sn=nesmith\)\" cn sn
telephoneNumber
Comment 2 Need Real Name 2003-03-06 12:17:13 EST
Created attachment 90494 [details]
debug output from source compile - no segfault

/usr/local/openldap-2.1.14/bin/ldapsearch -d -1 -LLL -x -ZZ -h vicar
\"\(sn=nesmith\)\" cn sn telephoneNumber
Comment 3 Need Real Name 2003-03-06 12:17:52 EST
Created attachment 90495 [details]
ldd output for the two different versions of ldapsearch
Comment 4 Timo Kokkonen 2003-06-19 10:34:36 EDT
I have observed similar segmentation faults when running ldapsearch against
Novell's LDAP server (using TLS). I am also using RH9 and

openldap-2.0.27-8
openldap-clients-2.0.27-8


It should be noted that ldapsearch works fine in RH7.2 that has same 
version of the openldap package:

openldap-clients-2.0.27-2.7.3
openldap-2.0.27-2.7.3

Comment 5 John Koyle 2003-07-09 14:45:35 EDT
I'm having the same problem.  ldapsearches from redhat 7.x and 8.0 work fine. 
Only redhat 9 is having trouble.

I've double checked that the cert running on the ldap server matches the host
listed in /etc/ldap.conf.

If I run getent passwd it segfaults when it attempts to contact the ldap server
as well.  
Comment 6 Josh Lothian 2003-07-10 12:24:46 EDT
I have the same problem as well.

It only occurs if in my openssl.cnf, I define:

subjectAltName=something.domain

under the [usr_cert] section before creating my certs.  Without this setting,
all works fine.  However, this is needed to have the certificate validate for
multiple hostnames.

Setting LD_LIBRARY_PATH to point at openldap libraries that I compiled myself
(2.1.21) works fine for programs like ldapsearch.  However, this still doesn't
fix programs like finger that go through the pam_ldap and nss_ldap modules.  The
box is fully up2date'd.
Comment 7 Neil Dunbar 2003-08-22 04:33:25 EDT
Created attachment 93850 [details]
backport of 2.1.22 ldap_pvt_check_hostname

This is a patch that I applied by taking the OL 2.1.22 codebase and backporting
to 2.0.27. It seems to fix the segfaulting when presented with a cert with a
subjectAltName.
Comment 8 Neil Dunbar 2003-08-22 04:38:47 EDT
I think that the problem stems from changes in the extension handling API within
OpenSSL - so OL probably works if you don't have a DNS subjectAltName extension
in your server cert. Bad news for me - all of HP's directory server certs have
subjectAltNames [and it was my decision to put them there - ack!]. The core
dumps I got were always within ldap_pvt_check_hostname, so I fiddled with the
2.1.22 routine of the same name until it compiled within 2.0.27.

Seems to work OK for me. By the way, I had to recompile nss_ldap after doing
this - for some reason it stopped working until I did a recompile (no changes,
just recompiled from the SRPM).

Neil
Comment 9 Ronny Bremer 2003-09-23 09:36:32 EDT
verified with Novell eDirectory 8.7 SP1

if the certificate (created by default btw during server installation) contains
an alternateName, ldapsearch will segfault with -ZZ (RedHat 9, up2date'd fully)

manually recreating the certificate without the alternateName works fine.

-> waiting on RH update :)
Comment 10 Erik Forsberg 2003-10-16 07:58:29 EDT
*** Bug 107145 has been marked as a duplicate of this bug. ***
Comment 11 Jason Heiss 2003-12-15 16:10:20 EST
This is still broken in RHEL 3.  It has caused us to turn off SSL for
LDAP on all of our boxes, which I really would prefer not to do.  It
also causes Samba to fail when pointed at our LDAP servers unless I
turn off SSL in Samba as well.  Our LDAP servers have subject
alternative name fields in their SSL certificates because they are
behind a load balancer.
Comment 12 Mike Austin 2003-12-18 18:56:43 EST
Yes, this is a problem for us in RedHat 9 and ReHat EL 3.

We rebuild openldap with the 2.1 patch listed above, and it all works
fine now.

When will this be an official RedHat fix?
Comment 13 Need Real Name 2004-01-06 23:11:22 EST
Here is brief overview of how I got my system fixed:

Download openldap-2.0.27.tgz from www.openldap.org.
Save patch file (Additional Comment #7 From Neil Dunbar on 2003-08-22
04:33) to the same directory.

tar zxvf openldap-2.0.27.tgz
patch -p0 < file.patch

cd openldap-2.0.27
export CPPFLAGS="-I/usr/kerberos/include"
./configure --with-tls
make depend
make

At this point you can test your ldap binaries (including
openldap-2.0.27/clients/tools/ldapsearch).

make install

I also needed to fix LDAP TLS in PHP, so I did the following:

Download the SRPM for your current PHP RPM from a RedHat mirror (I
used php-4.2.2-17.2.src.rpm).

rpmbuild --rebuild php-4.2.2-17.2.src.rpm

A lot will happen here, be patient.

cd /usr/src/redhat/RPMS/<yourarch>

You should see all new PHP RPMS, you really only need to remove the
old ldap one and install the new one instead.

rpm -e php-ldap-4.2.2-17.2
rpm -ivh php-ldap-4.2.2-17.2.<yourarch>.rpm

You can follow a similar process for any other programs that have
SRPMS and available and need openldap fixed.
Comment 14 Need Real Name 2004-01-07 00:43:35 EST
I created some RPMs for OpenLDAP that have the patch applied to them
on my website (http://nabber00.hopto.org/projects/openldap/) for
anyone interested.
Comment 15 Bert de Bruijn 2004-02-23 09:51:30 EST
The rpms from http://nabber00.hopto.org/projects/openldap/ fix the 
ldapsearch segfault for me, but other utilities using nss still 
segfault (finger, chown, id, ...).

System is a fully up2date Red Hat Linux 9.
# chown bob /tmp/aa
Segmentation fault
# finger bob
Segmentation fault
# id bob
Segmentation fault

This works perfectly if /etc/ldap.conf says "ssl no" instead of "ssl 
on".

# chown bob /tmp/aa
# finger bob
Login: bob                          Name: Bert
Directory: /home/bob                Shell: /bin/ksh
Never logged in.
No mail.
No Plan.
# id bob
uid=2011(bob) gid=2011 groups=2011


Comment 16 Steven Seed 2004-03-09 21:50:17 EST
Created attachment 98416 [details]
strace of login process which segfaults
Comment 17 Steven Seed 2004-03-09 21:52:02 EST
I also experience the Segmentation fault in login when using ldap with
pam and ssl is enabled. Partial strace of login attached (id=98416)
Comment 18 Levente Farkas 2004-05-11 12:20:42 EDT
After I rebuild openldap-2.1.29-1 from fc2t3 (with db-4.1.25, since
rh9 and rhel3 contains this version) and it doesn't help I rebuild
nss_ldap-217-1 (but with the lastest pam_ldap 169 from padl.com and
with db-4.1.25 since openldap was compiled with this version of db)
everything works with start_tls and tls_checkpeer (this second
parameter was the real reason of the crash). the rpms at:
http://www.lfarkas.org/openldap/
Comment 19 Bill Nottingham 2006-08-04 23:38:16 EDT
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Comment 21 Bill Nottingham 2007-01-02 13:34:56 EST
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
f you are currently still running Red Hat Linux 7.3 or 9, you are strongly
advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux
or comparable. Some information on which option may be right for you is
available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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