CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.1)  
ID

CWE-267: Privilege Defined With Unsafe Actions

Weakness ID: 267
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.269Improper Privilege Management
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.623Unsafe ActiveX Control Marked Safe For Scripting
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege / Sandbox Issues
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.623Unsafe ActiveX Control Marked Safe For Scripting
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

A user can access restricted functionality and/or sensitive information that may include administrative functionality and user accounts.
+ Demonstrative Examples

Example 1

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

(bad code)
Example Language: Java 
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 the 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.

+ Observed Examples
ReferenceDescription
Roles have access to dangerous procedures (Accessible entities).
Untrusted object/method gets access to clipboard (Accessible entities).
Gain privileges using functions/tags that should be restricted (Accessible entities).
Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).
Bypass domain restrictions using a particular file that references unsafe URI schemes (Accessible entities).
Script does not restrict access to an update command, leading to resultant disk consumption and filled error logs (Accessible entities).
"public" database user can use stored procedure to modify data controlled by the database owner (Unsafe privileged actions).
User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).
Allows attachment to and modification of privileged processes (Unsafe privileged actions).
User with privilege can edit raw underlying object using unprotected method (Unsafe privileged actions).
Inappropriate actions allowed by a particular role(Unsafe privileged actions).
Untrusted entity allowed to access the system clipboard (Unsafe privileged actions).
Extra Linux capability allows bypass of system-specified restriction (Unsafe privileged actions).
User with debugging rights can read entire process (Unsafe privileged actions).
Non-root admins can add themselves or others to the root admin group (Unsafe privileged actions).
Users can change certain properties of objects to perform otherwise unauthorized actions (Unsafe privileged actions).
Certain debugging commands not restricted to just the administrator, allowing registry modification and infoleak (Unsafe privileged actions).
+ Potential Mitigations

Phases: Architecture and Design; Operation

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

Phases: Architecture and Design; Operation

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.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
+ Notes

Maintenance

This overlaps authorization and access control problems.

Maintenance

Note: there are 2 separate sub-categories here:

- privilege incorrectly allows entities to perform certain actions
- object is incorrectly accessible to entities with a given privilege
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnsafe Privilege
+ References
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe Privilege

More information is available — Please select a different filter.
Page Last Updated: March 29, 2018