The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
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/
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum