Red Hat Bugzilla – Bug 207286
CVE-2006-5170 When using LDAP for authentication, xscreensaver allows access if account locked out.
Last modified: 2015-01-07 19:14:34 EST
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.
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
Xscreensaver does not deny access to locked out accounts.
Xscreensaver should not allow access to a locked out account.
It sounds like your pam stack may be misconfigured.
can you attach your /etc/pam.d/system-auth file?
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
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?
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.
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.
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?
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.
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
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.
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
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.
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
Created attachment 136939 [details]
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.
(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.
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.
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!
Does this bug affect all ldap servers, or only Fedora/RHDS?
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 (220.127.116.11.18.104.22.168.22.214.171.124) suggests that IBM/Tivoli
and Sun (of course) also implement it.
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?
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.
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.
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.