SEC03-J. Do not allow tainted variables in doPrivileged blocks

Do not operate on tainted data in a doPrivileged() block. An attacker can supply malicious input that could result in privilege escalation attacks.

Noncompliant Code Example

This noncompliant code example accepts a tainted filename argument. An attacker can supply the pathname of a sensitive password file, thus allowing an unprivileged user to access a protected file.

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);
        }
      }
    );
    // do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forward to handler and log
  }
}

Compliant Solution (Built-in Filename and Path)

This compliant solution explicitly hardcodes the name of the file and confines the variables used in the privileged block to the same method. This ensures that no malicious file can be loaded by exploiting the privileges of the corresponding code.

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);
        }
      }
    );
    // do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forward to handler and log
  }
}

Risk Assessment

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

Automated Detection

Tools that support Taint Analysis enable code usage that is substantially similar to the Noncompliant Code Example. Typical taint analysis assumes that a method or methods exist(s) that can "clean" 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 necessarily assume that the cleaning methods are always successful; reality may vary.

Because the annotations used by the analysis tools vary, we present a notional example here.

private void privilegedMethod(final String filename) throws FileNotFoundException {
  final String cleanFilename;
  try {
    cleanFilename = cleanAFilenameAndPath(filename);
  } catch (/* exception as per spec of cleanAFileNameAndPath */) {
    // log 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);
        }
      }
    );
    // do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forward to handler and log
  }
}

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"

MITRE CWE: CWE-732 "Incorrect Permission Assignment for Critical Resource"

Bibliography

[[API 2006]] method doPrivileged()
[[Gong 2003]] Sections 6.4, "AccessController" and 9.5 "Privileged Code"
[[Jovanovic 2006]] "Pixy: A Static Analysis Tool for Detecting Web Application Vulnerabilities"

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