The software attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
Extended Description
If the drop fails, the software will continue to run with the raised privileges, which might provide additional access to unprivileged users.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
All
Modes of Introduction
This issue is likely to occur in restrictive environments in which the
operating system or application provides fine-grained control over privilege
management.
Common Consequences
Scope
Effect
Access Control
Technical Impact: Gain privileges / assume
identity
If privileges are not dropped, neither are access rights of the user.
Often these rights can be prevented from being dropped.
Access Control
Non-Repudiation
Technical Impact: Gain privileges / assume
identity; Hide activities
If privileges are not dropped, in some cases the system may record
actions as the user which is being impersonated rather than the
impersonator.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
This code attempts to take on the privileges of a user before
creating a file, thus avoiding performing the action with unnecessarily high
privileges:
(Bad Code)
Example Languages: C and C++
bool DoSecureStuff(HANDLE hPipe) {
bool fDataWritten = false;
ImpersonateNamedPipeClient(hPipe);
HANDLE hFile = CreateFile(...);
/../
RevertToSelf()
/../
}
The call to ImpersonateNamedPipeClient may fail, but the return value
is not checked. If the call fails the code may execute with higher
privileges than intended. In this case, an attacker could exploit this
behavior to write a file to a location he does not have access to.
Program does not check return value when invoking
functions to drop privileges, which could leave users with higher privileges
than expected by forcing those functions to
fail.
Program does not check return value when invoking
functions to drop privileges, which could leave users with higher privileges
than expected by forcing those functions to
fail.
Potential Mitigations
Phase: Architecture and Design
Strategy: Separation of Privilege
Compartmentalize the system to have "safe" areas where trust
boundaries can be unambiguously drawn. Do not allow sensitive data to go
outside of the trust boundary and always be careful when interfacing
with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
Phase: Implementation
In Windows make sure that the process token has the
SeImpersonatePrivilege(Microsoft Server 2003).
Phase: Implementation
Always check all of your return values.
Other Notes
In Microsoft Operating environments that have access control,
impersonation is used so that access checks can be performed on a client
identity by a server with higher privileges. By impersonating the client,
the server is restricted to client-level security -- although in different
threads it may have much higher privileges. Code which relies on this for
security must ensure that the impersonation succeeded-- i.e., that a proper
privilege demotion happened.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Description
