Class · High

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.

CWE-269 · Class Level ·15 CVEs ·3 Mitigations

Description

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

Privilege Escalation Guide

Read our in-depth guide on exploiting and mitigating this weakness

Potential Impact

Access Control

Gain Privileges or Assume Identity

Demonstrative Examples

This code temporarily raises the program's privileges to allow creation of a new user folder.
Bad
def makeNewUserDir(username):
                        if invalidUsername(username):
                              
                                 
                                 #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.
The following example demonstrates the weakness.
Bad
seteuid(0);
                     /* do some stuff */
                     
                     seteuid(getuid());
The following example demonstrates the weakness.
Bad
AccessController.doPrivileged(new PrivilegedAction() {
                        public Object run() {
                                 // privileged code goes here, for example:
                                 System.loadLibrary("awt");return null;
                                 // nothing to return
                                 
                           }
This code intends to allow only Administrators to print debug information about a system.
Bad
public enum Roles {ADMIN,USER,GUEST}
                     public void printDebugInfo(User requestingUser){
                        if(isAuthenticated(requestingUser)){
                              switch(requestingUser.role){
                                    case GUEST:System.out.println("You are not authorized to perform this command");break;
                                       default:System.out.println(currentDebugState());break;
                                    
                                 }
                           }else{System.out.println("You must be logged in to perform this command");}
                     }
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.

Mitigations & Prevention

Architecture and DesignOperation

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 Methods

  • Automated Static Analysis High — 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 sea

Real-World CVE Examples

CVE IDDescription
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 (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
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).

Taxonomy Mappings

  • PLOVER: — Privilege Management Error
  • ISA/IEC 62443: Part 2-4 — Req SP.03.08 BR
  • ISA/IEC 62443: Part 3-2 — Req CR 3.1
  • ISA/IEC 62443: Part 3-3 — Req SR 1.2
  • ISA/IEC 62443: Part 3-3 — Req SR 2.1
  • ISA/IEC 62443: Part 4-1 — Req SD-3
  • ISA/IEC 62443: Part 4-1 — Req SD-4
  • ISA/IEC 62443: Part 4-1 — Req SI-1
  • ISA/IEC 62443: Part 4-2 — Req CR 1.1
  • ISA/IEC 62443: Part 4-2 — Req CR 2.1

Frequently Asked Questions

What is CWE-269?

CWE-269 (Improper Privilege Management) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

How can CWE-269 be exploited?

Attackers can exploit CWE-269 (Improper Privilege Management) to gain privileges or assume identity. This weakness is typically introduced during the Architecture and Design, Implementation, Operation phase of software development.

How do I prevent CWE-269?

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

What is the severity of CWE-269?

CWE-269 is classified as a Class-level weakness (High abstraction). It has been observed in 15 real-world CVEs.