Bug 207286 - CVE-2006-5170 When using LDAP for authentication, xscreensaver allows access if account locked out.
Summary: CVE-2006-5170 When using LDAP for authentication, xscreensaver allows access ...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap   
(Show other bugs)
Version: 4.4
Hardware: x86_64 Linux
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
Whiteboard: impact=moderate,source=redhat,public=...
Keywords: Reopened, Security
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-20 14:27 UTC by Steve Rigler
Modified: 2015-01-08 00:14 UTC (History)
6 users (show)

Fixed In Version: RHSA-2006-0719
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-15 14:26:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tcpdump output (11.10 KB, application/x-extension-out)
2006-09-22 12:29 UTC, Steve Rigler
no flags Details
updated source package with proposed patch (362.02 KB, application/octet-stream)
2006-09-22 22:01 UTC, Nalin Dahyabhai
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0719 normal SHIPPED_LIVE Moderate: nss_ldap security update 2006-11-15 14:26:02 UTC
PADL Software 291 None None None Never

Description Steve Rigler 2006-09-20 14:27:40 UTC
Description of problem:

We are using Fedora Directory Server for authentication with password policies
configured.  When a user's account is locked out, xscreensaver allows access for
that user with *any* password.

Version-Release number of selected component (if applicable):

This has only been noticed in xscreensaver-4.18-5.rhel4.11.  We have not tried
any prior versions supplied with RHEL 4.

How reproducible:


Steps to Reproduce:
1. Configure system to authenticate against Fedora Directory Server.
2. Log in as a user and start xscreensaver
3. Lockout the account (in this case, 3 bad passwords causes a lockout)
4. Enter any password into the xscreensaver login prompt
Actual results:

Xscreensaver does not deny access to locked out accounts.

Expected results:

Xscreensaver should not allow access to a locked out account.

Additional info:

Comment 1 Ray Strode [halfline] 2006-09-20 15:10:35 UTC
It sounds like your pam stack may be misconfigured.

can you attach your /etc/pam.d/system-auth file?

Comment 2 Steve Rigler 2006-09-20 15:17:25 UTC
The system was kickstarted using:

auth  --useshadow  --enablecache --enableldap --enableldapauth --ldapserver <our
ldap server> --ldapbasedn=<our basedn> --enableldaptls

Here's the /etc/pam.d/system-auth it generated:
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     [default=bad success=ok user_unknown=ignore]
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so

Comment 3 Ray Strode [halfline] 2006-09-20 16:52:54 UTC
Oh I see now.

Your pam configuration looks fine, I think.  The problem is probably because of
this bit in xscreensaver's source code:

      /* We don't actually care if the account modules fail or succeed,
       * but we need to run them anyway because certain pam modules
       * depend on side effects of the account modules getting run.
      status2 = pam_acct_mgmt (pamh, 0);

I think the reason we don't care if it fails or succeeds is so that a system
doesn't end up in a situation where the screen can't be unlocked.  I'm not 100%
sure this is a compelling rationale though.

I'm going to add some other people to this bug report to get opinions on which
behavior is right. Tomas, Nalin, what do you guys think?

Comment 4 Tomas Mraz 2006-09-20 17:00:06 UTC
I think it's OK as is, as the user had the access before the screen was locked
and the screensaver is probably not the right place for disallowing him to login.

It wouldn't work for users from /etc/shadow anyway.

Comment 5 Ray Strode [halfline] 2006-09-20 17:24:03 UTC
That sounds reasonable to me. Another point is, if the screen doesn't happen to
be locked when the user is revoked, the user still has full access to the machine.

Steve, we're going to close this out.  If you'd like to request a future feature
for more immediate lock down of revoked credentials, please log on at
https://www.redhat.com/apps/support/ and file a ticket there.


Comment 6 Steve Rigler 2006-09-21 12:40:52 UTC
I'm confused about the rationale for keeping this as-is.  By implementing 
account lockouts we're (obviously) trying to prevent brute force attacks.  
They way it works now I don't even have to worry about guessing the user's 
password.  I can just walk into their office, put x number of bad passwords 
into xscreensaver's password dialog until their account locks and then the 
screensaver will let me in.  From our perspective this is extremely 

If I have to file a feature request to get this working how long will we have 
to wait for the functionality we need?

Comment 7 Tomas Mraz 2006-09-21 12:49:27 UTC
Well this would be certainly undesirable behaviour and I don't think it works
that way. At least with non-buggy LDAP server.

Are you really sure, that when the account locks the authentication starts
succeeding without proper password? That seems like a major security bug in
either the LDAP server or pam_ldap.

Comment 8 Steve Rigler 2006-09-21 12:59:16 UTC
I'm testing a mix of services on RHEL 3 and RHEL 4.  So far, when an account 
is locked every single service I've tested disallows access to a locked 
account except for xscreensaver on RHEL 4 U4 (I haven't checked U3 yet, but 
it's on my list for today).  On RHEL 3 xscreensaver disallows access as 

Comment 9 Ray Strode [halfline] 2006-09-21 14:28:20 UTC
Hi Steve,

There was a misunderstanding on my part regarding the severity of this issue.  I
thought the problem being reported was that a user can unlock the screen with
their correct password even after their accounted is locked.

You're saying that the user can log in with ANY password after their account is
locked.  That's a much more severe problem and I'm reopening the bug report. 
I'm sorry for the misunderstanding.

Comment 10 Nalin Dahyabhai 2006-09-22 05:17:13 UTC
I'm looking at the pam_ldap sources, and it looks to me as though, when the
directory server responds with a PasswordPolicyResponse control, the error for
the bind request itself is suppressed so that it can be reported later from the
pam_acct_mgmt() callback.

So in this case, xscreensaver gets a success result from pam_authenticate().  It
calls pam_acct_mgmt(), gets the error code which pam_ldap reports, and discards it.

Steve, if you can attach a dump of the traffic between the client and the
directory server (without SSL, using 'tcpdump -s 0'), we can verify that this is
indeed what's happening in your setup.

Comment 11 Tomas Mraz 2006-09-22 06:13:42 UTC
I'm really curious why it was implemented this way in pam_ldap. It doesn't seem
to be right behaviour at all. Regardless missing pam_acct_mgmt() result check in

Comment 12 Steve Rigler 2006-09-22 12:29:29 UTC
Created attachment 136939 [details]
tcpdump output

I set the lockout threshold down to 1 bad password attempt.  This tcpdump is of
the initial bad password and then a second attempt using the same bad password
where xscreensaver allows access.

Comment 13 Nalin Dahyabhai 2006-09-22 20:59:15 UTC
(In reply to comment #11)
> I'm really curious why it was implemented this way in pam_ldap. It
> doesn't seem to be right behaviour at all. Regardless missing
> pam_acct_mgmt() result check in screensaver.

I think the intent is to keep track of failure status which was received
as part of the authentication response from the server, so that it can be
reported from the account management phase, which is when the PAM spec
says the application will expect it.

Comment 14 Nalin Dahyabhai 2006-09-22 22:01:04 UTC
Created attachment 136980 [details]
updated source package with proposed patch

Steve, can you rebuild the attached package and give it a try?	I
think the patch is correct, and will solve the problem, but I don't
have a suitable test environment at the moment.

Comment 15 Steve Rigler 2006-09-22 22:26:00 UTC
This package clears up the immediate issue with xscreensaver.  I can now lockout
the user's account and xscreensaver won't let me back in no matter what password
I give it.

The only side-affect I've noticed is that other services (gdm and telnet) don't
provide a notification that the account is locked.  This isn't a show-stopper
for us in any way and it might even be debatable (from a security perspective)
whether it's really necessary to provide that much information for a login failure.

Thanks for the quick turn around!

Comment 16 Josh Bressers 2006-09-27 20:33:20 UTC

Does this bug affect all ldap servers, or only Fedora/RHDS?

Comment 17 Nalin Dahyabhai 2006-09-27 21:18:59 UTC
It's triggered by servers which implement the control.  I don't
really know how common it is, but my understanding is that current
versions of OpenLDAP also implement it.  A web search for the
control's OID ( suggests that IBM/Tivoli
and Sun (of course) also implement it.

Comment 18 Josh Bressers 2006-09-29 14:26:59 UTC

I'm under the impression we shold call this a secuirty issue and get a CVE id. 
Do you know if this issue also affects RHEL2.1, RHEL3, and Fedora Core?

Comment 20 Nalin Dahyabhai 2006-10-04 14:33:09 UTC
The support for parsing and using the data from a password policy control
received in the bind response was introduced in pam_ldap 169, so only RHEL
4 and Fedora Core versions 3 and later are affected.

Comment 21 Josh Bressers 2006-10-04 19:09:16 UTC
I'm opening up some private comments to help clarify exactly what this issue is.
 It's worth of a CVE id, which I'm asking MITRE for.

Comment 29 Red Hat Bugzilla 2006-11-15 14:26:25 UTC
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.