Red Hat Bugzilla – Bug 209361
CVE-2006-5170 When using LDAP for authentication, xscreensaver allows access if account locked out.
Last modified: 2008-05-06 12:26:35 EDT
+++ This bug was initially created as a clone of Bug #207286 +++
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.
-- Additional comment from email@example.com on 2006-09-22 01:17 EST --
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.
-- Additional comment from firstname.lastname@example.org on 2006-09-22 02:13 EST --
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
-- Additional comment from email@example.com on 2006-09-22 08:29 EST --
Created an attachment (id=136939)
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.
-- Additional comment from firstname.lastname@example.org on 2006-09-22 16:59 EST --
(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.
-- Additional comment from email@example.com on 2006-09-22 18:01 EST --
Created an attachment (id=136980)
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.
-- Additional comment from firstname.lastname@example.org on 2006-09-22 18:26 EST --
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!
-- Additional comment from email@example.com on 2006-09-27 16:33 EST --
Does this bug affect all ldap servers, or only Fedora/RHDS?
-- Additional comment from firstname.lastname@example.org on 2006-09-27 17:18 EST --
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.
-- Additional comment from email@example.com on 2006-09-29 10:26 EST --
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?
-- Additional comment from firstname.lastname@example.org on 2006-10-04 06:32 EST --
ping comment #18
-- Additional comment from email@example.com on 2006-10-04 10:33 EST --
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.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.