Bug 207286

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:
#%PAM-1.0
# 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]
/lib/security/$ISA/pam_ldap.so
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.

Thanks!

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 
undesirable.

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 
expected.

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.

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.

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.

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.

(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!

Nalin,

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 (1.3.6.1.4.1.42.2.27.8.5.1) suggests that IBM/Tivoli
and Sun (of course) also implement it.

Nalin,

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.

http://rhn.redhat.com/errata/RHSA-2006-0719.html