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 (2.10)  

CWE-271: Privilege Dropping / Lowering Errors

Weakness ID: 271
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software does not drop privileges before passing control of a resource to an actor that does not have those privileges.

Extended Description

In some contexts, a system executing with elevated permissions will hand off a process/file/etc. to another process or user. If the privileges of an entity are not reduced, then elevated privileges are spread throughout a system and possibly to an attacker.

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms



+ Common Consequences
Access Control

Technical Impact: Gain privileges / assume identity

If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.

Access Control

Technical Impact: Gain privileges / assume identity; Hide activities

If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.

+ Likelihood of Exploit


+ Demonstrative Examples

Example 1

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:
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.

+ Observed Examples
Program does not drop privileges after acquiring the raw socket.
Setuid program does not drop privileges after a parsing error occurs, then calls another program to handle the error.
Does not drop privileges in related groups when lowering privileges.
Does not drop privileges in related groups when lowering privileges.
Does not drop privileges before determining access to certain files.
Finger daemon does not drop privileges when executing programs on behalf of the user being fingered.
FTP server does not drop privileges if a connection is aborted during file transfer.
Program only uses seteuid to drop privileges.
Windows program running as SYSTEM does not drop privileges before executing other programs (many others like this, especially involving the Help facility).
Utility Manager launches winhlp32.exe while running with raised privileges, which allows local users to gain system privileges.
Setuid program does not drop privileges before executing program specified in an environment variable.
Setuid program does not drop privileges before processing file specified on command line.
Service on Windows does not drop privileges before using "view file" option, allowing code execution.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

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.

Phases: Architecture and Design; Operation

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

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory265Privilege / Sandbox Issues
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base269Improper Privilege Management
Research Concepts (primary)1000
ChildOfCategoryCategory901SFP Primary Cluster: Privilege
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base272Least Privilege Violation
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base273Improper Check for Dropped Privileges
Development Concepts (primary)699
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base274Improper Handling of Insufficient Privileges
Research Concepts1000
+ Causal Nature


+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPrivilege Dropping / Lowering Errors
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Dropping Privileges Permanently", Page 479.. 1st Edition. Addison Wesley. 2006.
+ 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
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description, Maintenance_Notes
2009-12-28CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations

More information is available — Please select a different filter.
Page Last Updated: January 18, 2017