Page History

It is important to disallow operations on tainted input in a doPrivileged() block. This is because an adversary may Do not operate on unvalidated or untrusted data (also known as tainted data) in a privileged block. An attacker can supply malicious input that may could result in indirect privilege escalation attacks. Appropriate mitigations include hard coding values rather than accepting arguments (when appropriate) and validating or sanitizing data before performing privileged operations (see IDS00-J. Prevent SQL injection).

Noncompliant Code Example

This noncompliant code example accepts a tained filename tainted path or file name as an argument. An adversary could supply the name of a sensitive password file, complete with the path and consequently force operations to be performed on the wrong fileattacker can access a protected file by supplying its path name as an argument to this method.

private void privilegedMethod(final String filename) throws FileNotFoundException {
  final FileInputStream f[]={null}; 
                              throws FileNotFoundException {
  try {
    FileInputStream fis =
        (FileInputStream) AccessController.doPrivileged(
          new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          f[0] = return new FileInputStream(filename);
        }
      }
    );
    // Do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // Forward to handler
  }
}

Compliant Solution (Input Validation)

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

private void privilegedMethod(final String filename) 
                              throws FileNotFoundException {
  final String cleanFilename;
  try {
    cleanFilename = cleanAFilenameAndPath(filename);
  } catch (PrivilegedActionException e/* exception as per spec of cleanAFileNameAndPath */) {
  /*  // Log or forward to handler */ }
  // do 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
  }
}

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 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 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-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 Explicitly hardcode the name of the file and confine the privileged variables to the same method. This declares the variable as static final to prevent it from being modified. This technique ensures that no malicious file is can be loaded by exploiting the privileges of the corresponding codeprivileged method.

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

private void privilegedMethod(final String filename) throws FileNotFoundException {
  try final{
    FileInputStream f[]={null};
fis =
   try {
    (FileInputStream fis) = AccessController.doPrivileged(
            new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          f[0] =return new FileInputStream("/usr/home/filename"FILEPATH);
        }
      }
    );
    }
// Do something with the file }
and then close  );it
  } catch (PrivilegedActionException e) {
 /* forward to handler */ }
  // doForward something with the fileto handler and thenlog
 close it}
}

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[API 06|AA. Java References#API 06]\] [method doPrivileged()|http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#doPrivileged(java.security.PrivilegedAction)]
\[[Gong 03|AA. Java References#Gong 03]\] Sections 6.4, AccessController and 9.5 Privileged Code
\[[SCG 07|AA. Java References#SCG 07]\] Guideline 6-1 Safely invoke java.security.AccessController.doPrivileged
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 266|http://cwe.mitre.org/data/definitions/266.html] "Incorrect Privilege Assignment", [CWE ID 272|http://cwe.mitre.org/data/definitions/272.html] "Least Privilege Violation"

Tools that support taint analysis enable assurance of code usage that is substantially similar to the first compliant solution. Typical taint analyses assume that one or more methods exist that can 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 sanitization methods are always successful, but in reality, this may not be the case.

Related Guidelines

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

...

Image Added Image Added Image AddedSEC33-J. Do not expose standard APIs that use the immediate caller's class loader instance to untrusted code      01. Platform Security (SEC)      02. Declarations and Initialization (DCL)