[UNIX] Perl Module pam_per_user Authentication Bypassing

The following security advisory is sent to the securiteam mailing list, and can 
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Perl Module pam_per_user Authentication Bypassing
------------------------------------------------------------------------


SUMMARY

"The  <http://www.feep.net/PAM/pam_per_user/> pam_per_user module provides 
the ability to call different authentication mechanisms on a per-user 
basis."

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.

DETAILS

Vulnerable Systems:
 * pam_per_user versions prior to 0.4

Immune Systems:
 * pam_per_user version 0.4 (download  
<ftp://ftp.feep.net/pub/software/PAM/pam_per_user/pam_per_user-0.4.tar.gz> 
here)

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.

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.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:roth@xxxxxxxx> Mark D. Roth.
The original article can be found at:  <http://www.feep.net/~roth/> 
http://www.feep.net/~roth/



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
list-unsubscribe@xxxxxxxxxxxxxx 
In order to subscribe to the mailing list, simply forward this email to: 
list-subscribe@xxxxxxxxxxxxxx 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any 
kind. 
In no event shall we be liable for any damages whatsoever including direct, 
indirect, incidental, consequential, loss of business profits or special 
damages.