96767 2005-06-22 03:11 0000 sys-auth/{pam_ldap|nss_ldap} not using tls for referred connections 2005-07-14 03:21:24 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Other RESOLVED FIXED B3 [glsa] P2 minor --- 1 tigger@gentoo.org security@gentoo.org lcars@gentoo.org pam-bugs@gentoo.org robbat2@gentoo.org tigger@gentoo.org 2005-06-22 03:11:43 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 tigger@gentoo.org 2005-06-22 03:13:53 0000 setting upstream as fixes have been filed in the relevant bug systems. koon@gentoo.org 2005-06-22 03:35:51 0000 Cleaning up :) tigger@gentoo.org 2005-06-28 03:37:21 0000 Can we please being carrying this patch in the ebuilds? Upstream aren't responding and this is a serious issue. tigger@gentoo.org 2005-06-28 03:54:45 0000 s/being/begin/ :) adding robbat2 as this needs openldap lovin as well. koon@gentoo.org 2005-06-29 13:25:13 0000 ====================================================== Candidate: CAN-2005-2069 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2069 Reference: MISC:http://www.openldap.org/its/index.cgi/Incoming?id=3791 Reference: MISC:http://bugzilla.padl.com/show_bug.cgi?id=210 Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161990 pam_ldap and OpenLDAP, when connecting to a slave using TLS, does not use TLS for the subsequent connection if the client is referred to a master, which causes a password to be sent in cleartext and allows remote attackers to sniff the password. ====================================================== Robin: please patch (or comment) robbat2@gentoo.org 2005-07-03 11:55:47 0000 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. robbat2@gentoo.org 2005-07-03 12:10:56 0000 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. robbat2@gentoo.org 2005-07-03 12:16:08 0000 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). flameeyes@gentoo.org 2005-07-03 12:16:29 0000 Updating the package name :) dercorny@gentoo.org 2005-07-03 15:12:38 0000 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. tigger@gentoo.org 2005-07-03 15:41:10 0000 good call wrt nss_ldap. untested patch follows. if there are problems I'll try to fix first thing tomorrow. tigger@gentoo.org 2005-07-03 15:42:11 0000 Created an attachment (id=62564) tls patch for referrals for nss_ldap tigger@gentoo.org 2005-07-04 02:09:02 0000 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. lcars@gentoo.org 2005-07-04 03:41:37 0000 Well nss_ldap doesn't performs updates, so I don't think it's affected by this issue. lcars@gentoo.org 2005-07-04 03:45:46 0000 Ok as rob pointed out referrals are used not only for updates but for subtrees as well...so ignore me ;) koon@gentoo.org 2005-07-04 06:15:14 0000 lcars: any reason to clear our precious status whiteboard ? lcars@gentoo.org 2005-07-04 06:17:17 0000 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-- weeve@gentoo.org 2005-07-04 15:40:02 0000 pam_ldap-178-r1 and and openldap-2.1.30-r5 stable on sparc. hansmi@gentoo.org 2005-07-06 13:08:18 0000 Stable on ppc. robbat2@gentoo.org 2005-07-06 16:47:29 0000 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 ^^^^ corsair@gentoo.org 2005-07-07 03:37:04 0000 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. weeve@gentoo.org 2005-07-09 05:48:19 0000 Stable on SPARC blubb@gentoo.org 2005-07-11 05:03:44 0000 amd64 stable koon@gentoo.org 2005-07-13 07:16:24 0000 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. hansmi@gentoo.org 2005-07-13 07:42:56 0000 Stable on hppa and ppc. tigger@gentoo.org 2005-07-13 08:42:26 0000 stable on x86 corsair@gentoo.org 2005-07-13 13:24:28 0000 oh.. I didn't thought about that. nss_ldap-239-r1 is stable now on ppc64. sorry for the delay... koon@gentoo.org 2005-07-13 13:35:20 0000 Should be ready for GLSA koon@gentoo.org 2005-07-14 03:21:24 0000 GLSA 200507-13 (Removed misc arches tat did not have those packages keyworded anyway) 62564 2005-07-03 15:42 0000 tls patch for referrals for nss_ldap nss_ldap.patch text/plain LS0tIGxkYXAtbnNzLmMJMjAwNC0wOS0yOCAwMzoyMDoxMS4wMDAwMDAwMDAgKzAxMDAKKysrIGxk YXAtbnNzLmMubmV3CTIwMDUtMDctMDQgMDE6MzI6MTIuMDAwMDAwMDAwICswMTAwCkBAIC0zMzAs NiArMzMwLDM5IEBACiAKICAgdGltZWxpbWl0ID0gX19zZXNzaW9uLmxzX2NvbmZpZy0+bGRjX2Jp bmRfdGltZWxpbWl0OwogCisjaWZkZWYgSEFWRV9MREFQX1NUQVJUX1RMU19TCisgIGlmIChfX3Nl c3Npb24ubHNfY29uZmlnLT5sZGNfc3NsX29uID09IFNTTF9TVEFSVF9UTFMpCisgICAgeworICAg ICAgaW50IHZlcnNpb247CisKKyAgICAgIGlmIChsZGFwX2dldF9vcHRpb24KKwkgIChfX3Nlc3Np b24ubHNfY29ubiwgTERBUF9PUFRfUFJPVE9DT0xfVkVSU0lPTiwKKwkgICAmdmVyc2lvbikgPT0g TERBUF9PUFRfU1VDQ0VTUykKKwl7CisJICBpZiAodmVyc2lvbiA8IExEQVBfVkVSU0lPTjMpCisJ ICAgIHsKKwkgICAgICB2ZXJzaW9uID0gTERBUF9WRVJTSU9OMzsKKwkgICAgICBsZGFwX3NldF9v cHRpb24gKF9fc2Vzc2lvbi5sc19jb25uLCBMREFQX09QVF9QUk9UT0NPTF9WRVJTSU9OLAorCQkJ ICAgICAgICZ2ZXJzaW9uKTsKKwkgICAgfQorCX0KKworICAgICAgZGVidWcgKCI9PT4gc3RhcnRf dGxzIik7CisgICAgICBpZiAobGRhcF9zdGFydF90bHNfcyAoX19zZXNzaW9uLmxzX2Nvbm4sIE5V TEwsIE5VTEwpID09IExEQVBfU1VDQ0VTUykKKwl7CisJICBkZWJ1ZyAoIlRMUyBzdGFydHVwIHN1 Y2NlZWRlZCIpOworCX0KKyAgICAgIGVsc2UKKwl7CisJICBkZWJ1ZyAoIlRMUyBzdGFydHVwIGZh aWxlZCIpOworCSAgZG9fY2xvc2UgKCk7CisJICBkZWJ1ZyAoIjw9PSBkb19vcGVuIik7CisJICBy ZXR1cm4gTlNTX1VOQVZBSUw7CisJfQorICAgICAgZGVidWcgKCI8PT0gc3RhcnRfdGxzIik7Cisg ICAgfQorI2VuZGlmIC8qIEhBVkVfTERBUF9TVEFSVF9UTFNfUyAqLworCiAgIHJldHVybiBkb19i aW5kIChsZCwgdGltZWxpbWl0LCB3aG8sIGNyZWQsIHdpdGhfc2FzbCk7CiB9CiAjZWxzZQo=