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@feep.net> 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@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
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.
