Bug 166163 - CAN-2005-2641 pam_ldap policy vulnerability
CAN-2005-2641 pam_ldap policy vulnerability
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-08-17 14:15 EDT by Josh Bressers
Modified: 2015-01-07 19:10 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2005-767
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-17 03:50:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2005-08-17 14:15:54 EDT
This issue was discovered by Luke Howard

The text was scavanged from his CERT submission

Please describe the vulnerability.
- ----------------------------------

This vulnerability was introduced in pam_ldap-169, which included
preliminary support for draft-behera-ldap-password-policy-07.txt.

If a pam_ldap client authenticates against an LDAP server that
returns a passwordPolicyResponse control, but omits the optional
"error" field of the PasswordPolicyResponseValue, then the LDAP
authentication result will be ignored and the authentication
step will always succeed.

While any password policy error should be propagated to the
account management (authorization) step, under no circumstance
should the absence of the error field override the BindResponse

A fix that corrects this will be available in pam_ldap-180,
available from www.padl.com/OSS/pam_ldap.html.

What is the impact of this vulnerability?
- -----------------------------------------
 (For example: local user can gain root/privileged access, intruders
  can create root-owned files, denial of service attack,  etc.)

   a) What is the specific impact:

When pam_ldap is configured against a directory server that returns
the passwordPolicyResponse control in a BindResponse with no error
field, any user will be allowed to logon to the local system,
regardless of whether the underlying BindRequest succeeded.

This behaviour is likely to occur consistently, so one would expect
it to be noticed during the provisioning of the pam_ldap module.

   b) How would you envision it being used in an attack scenario:

One could exploit this by removing the error field from the encoded
passwordPolicyResponse on the wire if integrity protection is not
used on the underlying LDAP connection. However, this would be
contrary to the best practices for deploying pam_ldap (integrity
and confidentiality should be used). If integrity and confidentiality
protection are not used, then more trivial MITM attacks exist.

Otherwise, a competent system administrator deploying pam_ldap
with an LDAP server that triggers this vulnerability would likely
notice that all logons succeed during the initial configuration of
the software.

The only potentially dangerous exploit would be if it were
possible for a legitimate client authentication to trigger the
omission of the error field in the passwordPolicyResponse in a
manner which is unlikely to be noticed by an administrator
during the initial configuration of the software.
Comment 2 Josh Bressers 2005-08-22 17:24:42 EDT
Lifting embargo.
Comment 3 Taichi Yanagiya 2005-09-09 06:05:01 EDT
Don't this issue affect RHEL2.1(pam_ldap-145) and RHEL3(pam_ldap-164) ?
Comment 4 Mark J. Cox (Product Security) 2005-09-09 06:55:59 EDT
No, this issue was introduced in pam_ldap-169 and therefore RHEL2.1 and RHEL3
are not vulnerable to this issue
Comment 5 Taichi Yanagiya 2005-09-09 23:12:38 EDT
Comment 6 Red Hat Bugzilla 2005-10-17 03:50:34 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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