bugtraq - Security Flaw in pam_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20050912001255.GA28536@starbase.feep.net>
Date: Sun, 11 Sep 2005 19:12:55 -0500
From: "Mark D. Roth" <roth+pam_per_user@...p.net>
To: bugtraq@...urityfocus.com
Cc: Vijay Tandeker <vijayt@...ia.tejasnetworks.com>
Subject: 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@...ia.tejasnetworks.com> for
reporting this security hole.

-- 
Mark D. Roth <roth@...p.net>
http://www.feep.net/~roth/