Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Do not operate on unvalidated or untrusted data (also known as tainted data) in a doPrivileged() privileged block. An attacker can supply malicious input that could result in privilege escalation attacks. Appropriate mitigations include hard coding values rather than accepting arguments (when appropriate) , or validating (a.k.a. sanitizing) data before the privileged operationsand validating or sanitizing data before performing privileged operations (see IDS00-J. Prevent SQL injection).

Noncompliant Code Example

This noncompliant code example accepts a tainted filename path or file name as an argument. An attacker can supply the path name of a sensitive password file, consequently allowing an unprivileged user to access a protected fileaccess a protected file by supplying its path name as an argument to this method.

Code Block
bgColor#FFcccc

private void privilegedMethod(final String filename) 
                              throws FileNotFoundException {
  try {
    FileInputStream fis =
        (FileInputStream) AccessController.doPrivileged(
          new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          return new FileInputStream(filename);
        }
      }
    );
    // doDo something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forwardForward to handler and log
  }
}

Compliant Solution (Input Validation)

This compliant solution invokes a sanitization method the cleanAFilenameAndPath(cleanAFilenameAndPath) that can distinguish acceptable inputs from ) method to sanitize malicious inputs. Successful operation completion of the sanitization method indicates that the input is acceptable , and the doPrivileged() block can be executed.

Code Block
bgColor#ccccff

private void privilegedMethod(final String filename) 
                              throws FileNotFoundException {
  final String cleanFilename;
  try {
    cleanFilename = cleanAFilenameAndPath(filename);
  } catch (/* exception as per spec of cleanAFileNameAndPath */) {
    // logLog or forward to handler as appropriate based on specification
    // of cleanAFilenameAndPath
  }
  try {
    FileInputStream fis =
        (FileInputStream) AccessController.doPrivileged(
          new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          return new FileInputStream(cleanFilename);
        }
      }
    );
    // doDo something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forwardForward to handler and log
  }
}

One potential drawback of this approach is that effective sanitization methods can be difficult to write. A benefit of this approach is that it works well in combination with taint analysis (see the Automated Detection , below)section for this rule). For more information on how to perform secure file operations, see FIO00-J. Do not operate on files in shared directories.

Compliant Solution (Built-in File Name and Path)

Sanitization of tainted inputs always carries the risk that the data is not fully sanitized. Both file and path name equivalence and directory traversal are common examples of vulnerabilities arising from the improper sanitization of path and file name inputs (see FIO04 FIO16-J. Canonicalize path names before validating them). A design that requires an unprivileged user to access an arbitrary, protected file (or other resource) is always suspect. Consider alternatives such as using a hard code -coded resource name or permitting the user to select only from a list of options that are indirectly mapped to the resource names.

This compliant solution both explicitly hard codes the name of the file and also confines the variables used in the privileged block to the same method. This declares the variable as static final to prevent it from being modified. This technique ensures that no malicious file can be loaded by exploiting the privileges of the corresponding codeprivileged method.

Code Block
bgColor#ccccff

static final String FILEPATH = "/path/to/protected/file/fn.ext";

private void privilegedMethod() throws FileNotFoundException {
 
  try {
    FileInputStream fis =
        (FileInputStream) AccessController.doPrivileged(
            new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          return new FileInputStream(FILEPATH);
        }
      }
    );
    // doDo something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forwardForward to handler and log
  }
}

Risk Assessment

Allowing tainted inputs in privileged operations can lead to result in privilege escalation attacks.

Guideline

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC03

SEC01-J

high

High

likely

Likely

low

Low

P27

L1

Automated Detection

Tools that support taint analysis enable assurance of code usage that is substantially similar to the first compliant solution. Typical taint analyses assume that a method one or more methods exist (s) that can "clean" sanitize potentially tainted inputs, providing untainted outputs (or appropriate errors). The taint analysis then ensures that only untainted data is used inside the doPrivileged block. Note that the static analyses must necessarily assume that the cleaning sanitization methods are always successful; , but in reality, this may not be the case.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Related Guidelines

SCG 2007 Guideline 6-1. "Safely invoke java.security.AccessController.doPrivileged"

MITRE CWE: CWE-266 "Incorrect Privilege Assignment"

MITRE CWE: CWE-272 "Least Privilege Violation"

...

ToolVersionCheckerDescription
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

JAVA.IO.PERM.ACCESS
JAVA.IO.PERM

Accessing File in Permissive Mode (Java)
Permissive File Mode (Java)

Parasoft Jtest

Include Page
Parasoft_V
Parasoft_V

CERT.SEC01.PRIVILAvoid operating on tainted data in privileged blocks

Related Guidelines

MITRE CWE

CWE-266, Incorrect Privilege Assignment
CWE-272, Least Privilege Violation
CWE-732, Incorrect Permission Assignment for Critical Resource

...

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 9-3 / ACCESS-3: Safely invoke java.security.AccessController.doPrivileged

Android Implementation Details

The code examples using the java.security package are not applicable to Android, but the principle of the rule is applicable to Android apps.

Bibliography

[API 2014]

Method doPrivileged()

[Gong 2003]

Section 6.4, "AccessController"
Section 9.5, "Privileged Code"

[Jovanovic 2006]

Pixy: A Static Analysis Tool for Detecting Web Application Vulnerabilities


...

Image Added Image Added Image Added

Bibliography

Wiki Markup
\[[API 2006|AA. Bibliography#API 06]\] [method doPrivileged()|http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#doPrivileged(java.security.PrivilegedAction)]
\[[Gong 2003|AA. Bibliography#Gong 03]\] Sections 6.4, "AccessController" and 9.5 "Privileged Code"
\[[Jovanovic 2006|AA. Bibliography#Jovanovic 06]\] "Pixy: A Static Analysis Tool for Detecting Web Application Vulnerabilities"

SEC02-J. Guard doPrivileged blocks against untrusted invocation and leakage of sensitive data      Platform Security (SEC)      SEC04-J. Do not expose standard APIs that may bypass Security Manager checks to untrusted code