|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2005-2069: pam_ldap/openldap redirected SSL connections don't use SSL | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Thomas Biege <thomas> |
| Component: | Incidents | Assignee: | Security Team bot <security-team> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | andreas.taschner, meissner, mls, patch-request, ralf, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | patchinfos submitted | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Thomas Biege
2005-06-28 14:13:25 UTC
Hmm, I am able to reproduce the behavior described in the bug report. But I am undecided if it is really a bug or simply a missing feature in pam_ldap. pam_ldap just doesn't support referral chasing with START_TLS at the moment (this is what the pam_ldap patch adds). A possible workaround for this would be to tell the slave LDAP server to send and ldaps:// (LDAP over SSL) URL with the referral by setting updateref to "ldaps://master.server.com" in slapd.conf. I need to look closer into the libldap issue that is also described in this bug. Any idea what the other vendors are doing about this? No reaction from them so far. Except from Gentoo who founds the bug. From: Rob Holland <tigger@gentoo.org> To: vendor-sec@lst.de Cc: security@gentoo.org User-Agent: Mutt/1.5.8i Subject: [vendor-sec] Re: Openldap/pam_ldap TLS bug Errors-To: vendor-sec-admin@lst.de Date: Wed, 29 Jun 2005 09:10:07 +0100 On Tue, Jun 28, 2005 at 01:13:06PM +0100, Rob Holland wrote: > I have asked the Gentoo maintainers to carry patches for these issues in > our tree. I plan to release an advisory about this issue on Monday 28th > June. My apologies, this should have read Monday 4th July. -- rob holland - [ tigger@gentoo.org ] - Gentoo Audit Team [ 5251 4FAC D684 8845 5604 E44F D65C 392F D91B 4729 ] _______________________________________________ Yes I would call it a missing feature with security implications. It would be better to have this feature or to document this behaviour clearly. Just to make sure. Do you want to release a fix for our maintained products? Or do you just want this feature in future products? I am undecided right now. Let's see what other vendors do. rom: Josh Bressers <bressers@redhat.com> To: Rob Holland <tigger@gentoo.org> Cc: vendor-sec@lst.de, security@gentoo.org Subject: Re: [vendor-sec] Re: Openldap/pam_ldap TLS bug User-Agent: Mutt/1.4.1i Errors-To: vendor-sec-admin@lst.de Date: Wed, 29 Jun 2005 15:46:05 -0400 On Wed, Jun 29, 2005 at 09:10:07AM +0100, Rob Holland wrote: > On Tue, Jun 28, 2005 at 01:13:06PM +0100, Rob Holland wrote: > > > I have asked the Gentoo maintainers to carry patches for these issues in > > our tree. I plan to release an advisory about this issue on Monday 28th > > June. > > My apologies, this should have read Monday 4th July. Here is the CVE information from MITRE, it seems this issue is public. This is now sufficiently public, as a third party requested a CVE for this. - Steve ====================================================== 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. -- JB _______________________________________________ Vendor Security mailing list *** Bug 96311 has been marked as a duplicate of this bug. *** any update here? Mandrake fixed it. Did upstream fix it? If so I vote for fixing it as well. Any news on this one? The fix is not yet in the CVS of the OpenLDAP project. The pam_ldap fix also hasn't made it into the latest release. I'll try to find out what their plans are. Update: The pam_ldap part of the patch will be in the next pam_ldap release. I am not sure how clear the current situation is to folks using this module. If this missing feature is explained very well in the docs it is ok to fix it in stable only. If not and if the patch isn't too intrusive I would like to have it fixed in older version too. The problem is unfortunately not documented in any way. But both patches are really small and not very intrusive so it wouldn't be much of a problem to release fixes for older versions. I am currently discussing the libldap patch with the OpenLDAP developers they have some objections against it and might come up with another solution. I'll keep you informed. The result of the discussion with the OpenLDAP developers was, that they applied a slightly different patch to their CVS which in the result does the same as the orignial patch. I'll now submit fixed packages to STABLE (they should show up in 10.0 Beta3). Is an update for pam_ldap and openldap2-client is still desired for older version? If yes I'll submit fixes for those as well. Yes, please do so. Thanks. Affected Versions: everything since SLES8. That makes: sles8, sles9, 9.0, 9.1, 9.2 and 9.3 I am preparing the packages at the moment. I'd need patchinfos and a SWAMP ID. Note there is a special problem with the packages from 9.1. We made a version update for OpenLDAP on SLES9-SP2. This newer version has however not been released on 9.1. Any idea how such a case is handled? Just submit the packages i'll handle the rest. I do not know how to handle the version update clash. :( SM-Tracker-2129 CAN-2005-2069 /work/src/done/PATCHINFO/pam_ldap.patch.box /work/src/done/PATCHINFO/pam_ldap.patch.maintained /work/src/done/PATCHINFO/patchinfo-box.openldap2 /work/src/done/PATCHINFO/patchinfo.openldap2 /work/src/done/PATCHINFO/patchinfo.openldap2.sles9 Shouldn't openldap2-client be also in the patchinfo? Or is this a server only issue? At least they were not submitted to autobuild, so I think they are not needed. openldap2-client is a subpackage generated from openldap2 ... The fix is in libldap which is part of openldap2-client. To fix the problem the server packages would not be required. But if I understood Thorsten (kukuk) correctly it is better to alway release the complete set subpackage with a fix. Please ignore Thorsten, nobody else shares this opinion. Thanks, I corrected it. They now just includes "openldap2-client" Please also add openldap2-devel. (contains the header files and static libraries) Package is already checked in. Michael, schould I submit a new set of patchinfos? /work/src/done/PATCHINFO/patchinfo.openldap2 /work/src/done/PATCHINFO/patchinfo-box.openldap2 submitted patchinfos for the devel package packgaes approved |