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 (at) india.tejasnetworks (dot) com [email concealed]> for reporting this security hole. -- Mark D. Roth <roth (at) feep (dot) net [email concealed]> http://www.feep.net/~roth/