Privilege Chaining

Draft Base
Structure: Simple
Description

Privilege chaining occurs when an attacker combines two separate permissions or capabilities, neither of which is dangerous on its own, to perform a harmful action that neither permission should individually allow.

Extended Description

This vulnerability is like a security bypass puzzle. A system might correctly enforce that a user cannot directly delete a file or directly write to a system directory. However, if the user can first move a file into that protected directory (using one permission) and then delete any file they own there (using a second permission), they have effectively achieved an unauthorized deletion. The core failure is that the system's security checks evaluate each privilege in isolation, missing the dangerous sequence they enable when used together. To prevent this, developers must design authorization checks that consider context and history, not just the immediate action. This involves analyzing how privileges can interact over a session or transaction. Implementing mandatory access control (MAC), logging and monitoring for unusual privilege sequences, and adhering to the principle of least privilege are key defenses. Always ask: 'Could these two allowed actions be combined to achieve something we explicitly forbid?'

Common Consequences 1
Scope: Access Control

Impact: Gain Privileges or Assume Identity

A user can be given or gain access rights of another user. This can give the user unauthorized access to sensitive information including the access information of another user.

Potential Mitigations 3
Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
Phase: Architecture and DesignOperation
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Phase: Architecture and DesignOperation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Demonstrative Examples 1

ID : DX-128

This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.

Code Example:

Bad
Java
java
This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.
Observed Examples 4
CVE-2005-1736Chaining of user rights.
CVE-2002-1772Gain certain rights via privilege chaining in alternate channel.
CVE-2005-1973Application is allowed to assign extra permissions to itself.
CVE-2003-0640"operator" user can overwrite usernames and passwords to gain admin privileges.
References 1
Likelihood of Exploit

High

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Operation
Related Weaknesses
Taxonomy Mapping
  • PLOVER
Notes
RelationshipThere is some conceptual overlap with Unsafe Privilege.