Improper Privilege Management

Description

This vulnerability occurs when an application fails to correctly manage user permissions, allowing someone to perform actions or access data beyond their intended authority.

Extended Description

Improper privilege management is a core security flaw where the system's logic for granting, changing, or verifying user rights is broken. Instead of consistently enforcing a 'least privilege' model, it creates gaps where attackers or even regular users can escalate their access, modify settings, view sensitive information, or delete data they shouldn't touch. This often stems from flawed assumptions, missing checks, or errors in how roles and permissions are tracked throughout a user's session. To prevent this, developers must implement a centralized, deny-by-default authorization layer that validates every request against the user's current, verified privileges. Key strategies include using server-side checks for all actions, avoiding reliance on client-side controls, implementing proper session management, and conducting regular audits of permission assignments. Always explicitly verify 'who can do what' at the point of every action, never assuming the user interface or a previous check is sufficient.

Common Consequences 1

Scope: Access Control

Impact: Gain Privileges or Assume Identity

Detection Methods 1

Automated Static AnalysisHigh

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Potential Mitigations 3

Phase: Architecture and DesignOperation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

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.

Demonstrative Examples 5

ID : DX-126

This code temporarily raises the program's privileges to allow creation of a new user folder.

Code Example:

Bad

Python

python

#avoid CWE-22 and CWE-78* print('Usernames cannot contain invalid characters') return False try: ``` raisePrivileges() os.mkdir('/home/' + username) lowerPrivileges() except OSError: print('Unable to create new user directory for user:' + username) return False return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

ID : DX-97

The following example demonstrates the weakness.

Code Example:

Bad

/* do some stuff /

ID : DX-142

The following example demonstrates the weakness.

Code Example:

Bad

Java

java

// privileged code goes here, for example:* System.loadLibrary("awt"); return null;

java

ID : DX-127

This code intends to allow only Administrators to print debug information about a system.

Code Example:Bad
Java
java

While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.

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 15

CVE-2001-1555Terminal privileges are not reset when a user logs out.

CVE-2001-1514Does not properly pass security context to child processes in certain cases, allows privilege escalation.

CVE-2001-0128Does not properly compute roles.

CVE-1999-1193untrusted user placed in unix "wheel" group

CVE-2005-2741Product allows users to grant themselves certain rights that can be used to escalate privileges.

CVE-2005-2496Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.

CVE-2004-0274Product mistakenly assigns a particular status to an entity, leading to increased privileges.

CVE-2007-4217FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.

CVE-2007-5159OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.

CVE-2008-4638Composite: application running with high privileges (Execution with Unnecessary Privileges) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (Generation of Error Message Containing Sensitive Information).

CVE-2007-3931Installation script installs some programs as setuid when they shouldn't be.

CVE-2002-1981Roles have access to dangerous procedures (Accessible entities).

CVE-2002-1671Untrusted object/method gets access to clipboard (Accessible entities).

CVE-2000-0315Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).

CVE-2000-0506User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).

References 3

24 Deadly Sins of Software Security

Michael Howard, David LeBlanc, and John Viega

McGraw-Hill

2010

ID: REF-44

The Art of Software Security Assessment

Mark Dowd, John McDonald, and Justin Schuh

Addison Wesley

2006

ID: REF-62

Supplemental Details - 2022 CWE Top 25

MITRE

28-06-2022

https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails(2024-11-17)

ID: REF-1287

Likelihood of Exploit

Medium

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Architecture and Design

Implementation

Operation

Related Attack Patterns

Related Weaknesses

ChildOf:

Improper Access Control (CWE-284)

Taxonomy Mapping

PLOVER
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443
ISA/IEC 62443

Notes

MaintenanceThe relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (Improper Control of a Resource Through its Lifetime) and protection mechanism failures (Protection Mechanism Failure).