Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161990 - openldap password disclosure issue
Summary: openldap password disclosure issue
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jan Safranek
QA Contact: Jay Turner
URL:
Whiteboard: impact=moderate,public=20050628,sourc...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-28 21:42 UTC by Josh Bressers
Modified: 2015-01-08 00:10 UTC (History)
3 users (show)

Fixed In Version: openldap-2.2.13-4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-19 11:05:24 UTC


Attachments (Terms of Use)

Description Josh Bressers 2005-06-28 21:42:19 UTC
Openldap currently doesn't allow a client to specify that referred
connections should use TLS. This can lead to passwords being sent in the
clear despite having "ssl start_tls" in ldap.conf.

In a master+slaves LDAP infrastructure passwords are sent in the clear
when a user runs "passwd" on a machine where pam_ldap is configured to
use a slave server.

pam_ldap connects to the slave over TLS (as specified in the ldap.conf
file) and then gets referred to the master in order to make a change.
TLS is never started on the referred connection and pam_ldap attempts to
bind in the clear. If the master server is not setup to require TLS on
all connections, this may go unoticed, as passwd will function as
normal.

The only place a client is able to try and start_tls for a referred
connection is inside rebind_proc. However, a bug in a sanity check in
the openldap code means that openldap considers that TLS has already
been started on the referrred connection if it has been started on the
first connection (it always checks the first connection, rather than
checking the default), and so this won't work.

Bugs have been filed on both openldap and pam_ldap:

http://www.openldap.org/its/index.cgi/Incoming?id=3791

http://bugzilla.padl.com/show_bug.cgi?id=210

Comment 1 Josh Bressers 2005-06-28 21:43:25 UTC
This issue may also affect RHEL2.1 and RHEL3

Comment 2 Rob Holland 2005-07-04 20:34:33 UTC
It would have been nice if you'd mentioned my name after you copy+pasted my
advisory into this bug.

You're advisory is missing the nss_ldap package which is also affected.

http://bugzilla.padl.com/show_bug.cgi?id=211

You may also see that URL listed in my posting to full-disclosure or bugtraq, if
you'd prefer to copy+paste it from another of my reports.



Comment 3 Rob Holland 2005-07-04 21:01:36 UTC
Oh, and the original bug is at:

http://bugs.gentoo.org/show_bug.cgi?id=96767

Comment 4 John Haxby 2005-10-17 10:37:22 UTC
Why does _rebind_proc() in pam_ldap return PAM_SERVICE_ERR?   Surely it should
be returning an LDAP error code?

Comment 5 RHEL Product and Program Management 2007-06-08 11:44:28 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 8 Jan Safranek 2007-07-19 11:05:24 UTC
This bug was fixed long ago in openldap-2.2.13-4.


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