Bug 96767 - sys-auth/{pam_ldap|nss_ldap} not using tls for referred connections
|
Bug#:
96767
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Other
|
Status: RESOLVED
|
Severity: minor
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: tigger@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: sys-auth/{pam_ldap|nss_ldap} not using tls for referred connections
|
|
Keywords:
|
|
Status Whiteboard: B3 [glsa]
|
|
Opened: 2005-06-22 03:11 0000
|
pam_ldap will send credentials in plaintext if a slave ldap server refers it to
a master server during a password change operation. The ldap.conf "ssl
start_tls" setting is not enforced on referrals (and openldap doesn't currently
allow it due to a bug).
Worst case is that server admins are not enforcing tls server-side, in which
case passwd will appear to work fine, but will be sending stuff over the wire
in plaintext.
Two patches are needed to fix this, one for pam_ldap to request tls on
referrals, and one for openldap to accept the request.
http://bugzilla.padl.com/show_bug.cgi?id=210
http://www.openldap.org/its/index.cgi/Incoming?id=3791
setting upstream as fixes have been filed in the relevant bug systems.
Can we please being carrying this patch in the ebuilds? Upstream aren't
responding and this is a serious issue.
s/being/begin/ :)
adding robbat2 as this needs openldap lovin as well.
could security please check the code in nss_ldap as well, as it shares code
with pam_ldap last I checked, and thus may be vulnerable to the same problem.
pam_ldap is patched now.
both 176-r1 and 178-r1 have the patch.
Could arches please test 178-r1, and if it works, stable it. If it doesn't
work, try 176-r1 instead.
openldap is patched now.
2.1.30-r5 and 2.2.27-r1 have the patch.
2.1.30-r5 is the ebuild that should go stable.
2.2.27-r1 (and the 2.2 series in general) will be considered for stable in 30
days).
Updating the package name :)
Dear arches, please test sys-auth/pam_ldap-178-r1 and mark stable if possible
(if it fails, try 176-r1).
Please also try to mark openldap-2.1.30-r5 stable, thanks.
good call wrt nss_ldap. untested patch follows. if there are problems I'll try
to fix first thing tomorrow.
pam_ldap/nss_ldap ebuilds which have the tls problem fixed must DEPEND on
openldap ebuilds with the revelent library fix, otherwise they won't function.
Well nss_ldap doesn't performs updates, so I don't think it's affected by this
issue.
Ok as rob pointed out referrals are used not only for updates but for subtrees
as well...so ignore me ;)
lcars: any reason to clear our precious status whiteboard ?
Sorry :/ blame /usr/bin/links. I'll be more careful in the future (but honestly
it
was impossible to spot without a post-commit review). links--
pam_ldap-178-r1 and and openldap-2.1.30-r5 stable on sparc.
ok, nss_ldap is patched as well now. Hopefully there is nothing else affected
by
this bug. sorry about the delay.
arches:
please test nss_ldap-239-r1 first, but if that doesn't work, test 226-r1
instead.
sparc/ppc: sorry to bring you back, but ^^^^
openldap-2.1.30-r5: stable on ppc64
pam_ldap-178-r1: was never marked ppc64 in any way -> added ~ppc64
nss_ldap-239-r1: versions after 226 didn't compile, this one works again ->
added ~ppc64
I'll mark those packages with ~ppc64 stable in 30 days, if no errors occur.
GLSA is ready to go...
hppa,x86: please test and mark stable pam_ldap-178-r1 and nss_ldap-239-r1 (or
226-r1)
ppc: please test and mark stable nss_ldap-239-r1 (or 226-r1)
ppc64 : we'll need it for the GLSA before the 30 days period, as current stable
version is affected and the GLSA must go out. So please test and mark stable
nss_ldap-239-r1 if you can.
oh.. I didn't thought about that. nss_ldap-239-r1 is stable now on ppc64. sorry
for the delay...
GLSA 200507-13
(Removed misc arches tat did not have those packages keyworded anyway)
