CWE Reference
CWE-269: Improper Privilege Management
Official CWE-269 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Release 4.20weaknessDraft
Glexia's Take
CWE-269: Improper Privilege Management
Improper Privilege Management represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control: Gain Privileges or Assume Identity
Developer Pattern
CWE-269 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-269, 4.20.
Official CWE Definition
CWE-269: Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- This code temporarily raises the program's privileges to allow creation of a new user folder. 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.
- The following example demonstrates the weakness.
- This code intends to allow only Administrators to print debug information about a system. 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.
- 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. 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.
Remediation
- Architecture and Design,Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
Detection
- Automated Static Analysis: 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.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
- CWE-250: Execution with Unnecessary Privileges
- CWE-266: Incorrect Privilege Assignment
- CWE-267: Privilege Defined With Unsafe Actions
- CWE-268: Privilege Chaining
- CWE-284: Improper Access Control
- CWE-270: Privilege Context Switching Error
- CWE-271: Privilege Dropping / Lowering Errors
- CWE-274: Improper Handling of Insufficient Privileges
- CWE-648: Incorrect Use of Privileged APIs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.