[Bug 604593] Re: pam_unix "account" returns success on a user with an invalid shadow password.

[Steve Langasek]

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.

** Package changed: pam (Ubuntu) => libpam-ldap (Ubuntu)

** Bug watch added: Debian Bug tracker #583483
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583483

** Also affects: libpam-ldap (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583483
   Importance: Unknown
       Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/604593

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

Status in “libpam-ldap” package in Ubuntu:
  Confirmed
Status in “libpam-ldap” package in Debian:
  Unknown

Bug description:
  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)