Security Flaw in pam_per_user Module
Summary/Impact:
---------------
There is a security flaw in the pam_per_user PAM module that can allow
someone to authenticate as any user on the system, provided that they
already have the proper credentials for one account.
This security hole is fixed in pam_per_user-0.4, which is available
from:
http://www.feep.net/PAM/pam_per_user/
Details:
--------
The pam_per_user module allows different authentication mechanisms to
be used on a per-user basis. An external map file is used to map any
given user to an alternate PAM service name that should be used to
authenticate that user. The module then creates a new PAM
"subrequest" handle using that service name, and uses that PAM handle
to authenticate the user. This recursive use of PAM is transparent to
the calling application.
The PAM "subrequest" handle is cached by pam_per_user between calls.
In the typical case, the user name does not change between calls, so
this works fine. However, some applications (most notably /bin/login)
give the user a new login prompt each time they get the password
wrong, which can cause the user name to change.
Unfortunately, pam_per_user was not handling this case correctly. It
did not check to see if the user name had changed, which could result
in a user being allowed to authenticate using a different user's
credentials (see example below).
The module has been fixed to check whether the user name has changed
since the last call, and to recreate the "subrequest" handle if
needed.
Example:
--------
Assume the following two accounts exist:
foo (password foo)
bar
The login session might look like this:
login: foo
Password: bad_password
login: bar
Password: foo <-- NOTE: this is the correct password for user foo!
That would result in a successful authentication, because pam_per_user
is still using a subrequest handle for user foo, even though it is
trying to authenticate user bar. This means that anyone that knows
the password for user "foo" can login as user "bar" - or any other
user.
Notes:
------
At this time, the only application known to trigger this security hole
is /bin/login. However, any application that resets the PAM_USER item
after the first call to pam_authenticate(3) (or any of the other PAM
calls) will trigger the same hole.
Acknowledgment:
---------------
Many thanks to Vijay Tandeker <vijayt@xxxxxxxxxxxxxxxxxxxxxxx> for
reporting this security hole.
--
Mark D. Roth <roth@xxxxxxxx>
http://www.feep.net/~roth/