Least Privilege Violation

The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.


Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

The following example demonstrates the weakness.

setuid(0);
// Do some important stuff
setuid(old_uid);
// Do some non privileged stuff.

Example Two

The following example demonstrates the weakness.

AccessController.doPrivileged(new PrivilegedAction() {

  public Object run() {
    // privileged code goes here, for example:
    System.loadLibrary("awt");
    return null;
    // nothing to return

  }

Example Three

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.

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.

See Also

Comprehensive Categorization: Access Control

Weaknesses in this category are related to access control.

SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)

Weaknesses in this category are related to the rules and recommendations in the Platform Security (SEC) section of the SEI CERT Oracle Secure Coding Standard for Java.

Authorize Actors

Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have th...

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Entries with Maintenance Notes

CWE entries in this view have maintenance notes. Maintenance notes are an indicator that an entry might change significantly in future versions. This view was created...

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.