The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
Extended Description
New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.
Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.
Time of Introduction
Installation
Architecture and Design
Operation
Applicable Platforms
Languages
All
Modes of Introduction
If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.
An attacker will be able to gain access to any resources that are
allowed by the extra privileges. Common results include executing code,
disabling services, and reading restricted data.
Likelihood of Exploit
Medium
Detection Methods
Manual Analysis
This weakness can be detected using tools and techniques that require
manual (human) analysis, such as penetration testing, threat modeling,
and interactive tools that allow the tester to record and modify an
active session.
These may be more effective than strictly automated techniques. This
is especially the case with weaknesses that are related to design and
business rules.
Black Box
Use monitoring tools that examine the software's process as it
interacts with the operating system and the network. This technique is
useful in cases when source code is unavailable, if the software was not
developed by you, or if you want to verify that the build phase did not
introduce any new weaknesses. Examples include debuggers that directly
attach to the running process; system-call tracing utilities such as
truss (Solaris) and strace (Linux); system activity monitors such as
FileMon, RegMon, Process Monitor, and other Sysinternals utilities
(Windows); and sniffers and protocol analyzers that monitor network
traffic.
Attach the monitor to the process and perform a login. Look for
library functions and system calls that indicate when privileges are
being raised or dropped. Look for accesses of resources that are
restricted to normal users.
Note that this technique is only useful for privilege issues related
to system resources. It is not likely to detect application-level
business rules that are related to privileges, such as if a blog system
allows a user to delete a blog entry without first checking that the
user has administrator privileges.
Demonstrative Examples
Example 1
This code temporarily raises the program's privileges to allow
creation of a new user folder.
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.
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.
FTP 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.
Composite: application running with high
privileges allows user to specify a restricted file to process, which
generates a parsing error that leaks the contents of the file.
Installation script installs some programs as
setuid when they shouldn't be.
Potential Mitigations
Phases: Architecture and Design; Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.250.2]. 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.
Phase: Architecture and Design
Strategies: Separation of Privilege; Identify and Reduce Attack Surface
Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [R.250.2]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.
Phase: Implementation
Perform extensive input validation for any privileged code that must
be exposed to the user and reject anything that does not fit your strict
requirements.
Phase: Implementation
When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.
Phase: Implementation
If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [R.250.2]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.
Phases: Operation; System Configuration
Strategy: Environment Hardening
Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [R.250.4] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
7 Pernicious Kingdoms
Often Misused: Privilege Management
CERT Java Secure Coding
SER09-J
Minimize privileges before deserializing from a privilege
context
[R.250.5] [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.
[R.250.6] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Privilege Vulnerabilities", Page
477.. 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. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.
Description
