[Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix

[Richard Maciel Costa]

Tested pam_faillock module for pam on bionic.

Test consisted on setting up pam_faillock with the following
configuration, as described in the man page:

/etc/security/faillock.conf file example:
deny=4
unlock_time=1200
silent

/etc/pam.d/config file example:
auth     required       pam_faillock.so preauth
# optionally use requisite above if you do not want to prompt for the password
# on locked accounts
auth     sufficient     pam_unix.so
auth     [default=die]  pam_faillock.so authfail
auth     required       pam_deny.so
account  required       pam_faillock.so
# if you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures
account  required       pam_unix.so

A new user 'joas' was created and its password set. Then, initially, 4
logins were made through ssh and terminal, using the correct password.
All were successful.

User 'joas' was, then, logged out and 4 attempts to login with incorrect
password were made. Since pam_faillock module was set to lock on the 4th
incorrect attempt, another try was done, this time with the correct
password.

After confirming that the 'joas' account was locked, by trying, with the
correct password, additional times, the superuser account was used to
display the account stats ('faillock --user joas') and then used to
unlock the 'joas' account ('faillock --user joas --reset').

Then, again 4 logins were made using the correct password, in order to
check it was successfully authenticating.

Another test consisted on typing the wrong password 3 times, then typing
the correct one, to make sure the PAM module was properly resetting the
counter.

-- 
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/1927796

Title:
  [SRU]pam_tally2 can cause accounts to be locked by correct password.
  pam_faillock use is the recommended fix

Status in pam package in Ubuntu:
  Fix Committed
Status in pam source package in Bionic:
  Fix Committed
Status in pam source package in Focal:
  Fix Committed
Status in pam source package in Groovy:
  Fix Committed
Status in pam source package in Hirsute:
  Fix Committed
Status in pam source package in Impish:
  Fix Committed

Bug description:
  [IMPACT]
  There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71).

  There are already two customer cases from Canonical clients
  complaining about this behavior (00297697 and 00303806).

  Also, potentially, this will cause further problems in the future,
  since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to
  lock accounts when wrong passwords are used. And both benchmarks - but
  specially STIG - requires use of a lot of audit rules, which can lead
  to the busy node environment.

  The issue impacts all pam_tally2 versions distributed in all currently
  supported Ubuntu versions and also the next unreleased one. Note that,
  according to https://github.com/linux-pam/linux-pam/issues/71, there
  is no plan to fix this issue!

  [FIX]
  This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available.

  Note that we don't propose to remove pam_tally2, since not every user
  of this module is affected.

  [TEST]
  Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password.

  Note that, since the pam_tally2 issue is caused by a racing condition,
  with a hard to recreate environment (we could not even reproduce it
  with pam_tally2), we could not reproduce the conditions to test
  pam_faillock with.

  [REGRESSION POTENTIAL]
  The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions