pam_unix "account" returns success on a user with an invalid shadow password.

[Stephane Chazelas]

libpam-modules 1.1.1-2ubuntu5
on lucid amd64

The "account" module of pam_unix.so returns "success" if a user is known by getpwnam but is not in /etc/shadow.

Typcial example is when LDAP is enabled both in PAM and NSS.

Give the default settings for common-account:

account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so

That means that above whatever account restrictions are in place for LDAP are ignored because for a user successfully *authenticated" via LDAP, the *unix* "account" module will return success and the account module of pam_ldap won't even get called (hence the "security vulnerability").

After investigation in the source code of pam_unix, it seems it is because the "account" module of pam_unix recognises an unknown user as a valid shadow user because getspnam(3) returns a dummy entry looking like:
{sp_namp = 0x20cfa08 "test", sp_pwdp = 0x20cfa0d "*", sp_lstchg = 14802, sp_min = -1, sp_max = -1, sp_warn = -1, sp_inact = -1, sp_expire = -1, sp_flag = 0}
for unknown users.

And the pam_unix code checks for a NULL pwdp but not a "*" one:

#0 get_account_info (pamh=0x20486f0, name=0x20484e0 "test", pwd=0x7ffff56e3a50, spwdent=0x7ffff56e3a58) at passverify.c:206
206 if (*spwdent == NULL || (*spwdent)->sp_pwdp == NULL)

[Stephane Chazelas (stephane-chazelas)]

Sorry, please disregard this bug, It's because I've got ldap for "shadow" in /etc/nsswitch.conf. After removing it, getspnam(3) returns NULL on users not in /etc/shadow as expected.

We may still say that there's a bug because with a default install of libpam-ldap the "account" settings for the pam_ldap module still are overriden by that of the pam_unix one.

[Stephane Chazelas (stephane-chazelas)]

Actually, with "shadow compat ldap" in /etc/nsswitch.conf, I get "*" for the password because the system doesn't have access to the LDAP passwd field. So: pam_unix's "auth" returns failure because it can't verify the password and pam_ldap's auth returns true if the password match. So the fact that in that case pam_unix's "account" returns success is a bug IMHO.

[Stephane Chazelas (stephane-chazelas)]

To sum up, that bug could be renamed:

pam_unix "account" returns success on a user with an invalid shadow password.

sorry for the confusions.

[Steve Langasek (vorlon)]

Thank you for reporting this issue and helping to improve Ubuntu.

This is not a bug in pam_unix, which is deliberately configured such that a successful authorization return from either pam_unix *or* another stacked module is sufficient to permit a login. If pam_ldap access checks should always be enforced *in addition* to pam_unix, then pam_ldap's pam-auth-update profile should declare itself Account-Type: additional.

This appears to be the same as Debian bug #583483.