Least Privilege Violation
Weakness ID: 272 (Weakness Base)Status: Incomplete
+ Description

Description Summary

The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

An attacker may be able to access resources with the elevated privilege that he should not have been able to access. This is particularly likely in conjunction with another flaw -- e.g., a buffer overflow.

+ Demonstrative Examples

Example 1

(Bad Code)
Example Languages: C and C++ 
setuid(0);
//Do some important stuff//
setuid(old_uid);
// Do some non privileged stuff.
(Bad Code)
Example Language: Java 
method() {
AccessController.doPrivileged(new PrivilegedAction()) {

public Object run() {
//Insert all code here
}
};
}

Example 2

The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(Bad Code)
Example Language: C 
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.

+ Potential Mitigations

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

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

Phase: Architecture and Design

Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.

+ Other Notes

The failure to drop system privileges when it is reasonable to do so is not a vulnerability by itself. It does, however, serve to significantly increase the Severity of other vulnerabilities. According to the principle of least privilege, access should be allowed only when it is absolutely necessary to the function of a given system, and only for the minimal necessary amount of time. Any further allowance of privilege widens the window of time during which a successful exploitation of the system will provide an attacker with that same privilege. If at all possible, limit the allowance of system privilege to small, simple sections of code that may be called atomically.

When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class271Privilege Dropping / Lowering Errors
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory748CERT C Secure Coding Section 50 - POSIX (POS)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsLeast Privilege Violation
CLASPFailure to drop privileges when reasonable
CERT C Secure CodingPOS02-CFollow the principle of least privilege
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
17Accessing, Modifying or Executing Executable Files
35Leverage Executable Code in Nonexecutable Files
76Manipulating Input to File System Calls
+ Maintenance Notes

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings, Weakness Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Maintenance Notes
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-12-28CWE Content TeamMITREInternal
updated Potential Mitigations
Back to top