Page History

...

For example, suppose a web application must maintain a sensitive file of passwords for a web service, and suppose it must run untrusted code as well. The application could then enforce a security policy preventing most of itself, including any untrusted code, from accessing the sensitive file. But since it must also provide mechanisms for adding and changing passwords, it can use the doPrivileged() method to temporarily bypass its own security policy for the purpose of managing passwords. In this case, any doPrivileged() privileged block must prevent any information about passwords from being accessible to untrusted code.

Noncompliant Code Example

In this noncompliant code example, the doPrivileged() method is called from the openPasswordFile() method. The openPasswordFile() method is privileged and returns a FileInputStream for the sensitive password file to its caller. Because the method is public, it could be invoked by an untrusted caller.

public class PasswordManager {

  public static void changePassword() throws FileNotFoundException {
    FileInputStream fin = openPasswordFile();

    // test old password with password in file contents; change password
  }

  public static FileInputStream openPasswordFile() throws FileNotFoundException {
    final String password_file = "password";
    FileInputStream fin = null;
    try {
      fin = AccessController.doPrivileged(
         new PrivilegedExceptionAction<FileInputStream>() {
           public FileInputStream run() throws FileNotFoundException {
             // Sensitive action; can't be done outside doPrivileged()privileged block
             FileInputStream in = new FileInputStream(password_file);
             return in;
           }
         });
    } catch (PrivilegedActionException x) {
      Exception cause = x.getException();
      if (cause instanceof FileNotFoundException) {
        throw (FileNotFoundException)cause;
      } else {
        throw new Error("Unexpected exception type", cause); 
      }
    }
    return fin;
  }
}

Compliant Solution

In general, when any method containing the doPrivileged() a privileged block exposes a field (such as a reference) beyond its own boundary, it becomes trivial for untrusted callers to exploit the program.

...

public class PasswordManager {
  public static void changePassword() throws FileNotFoundException {
    // ...
  }

  private static FileInputStream openPasswordFile() throws FileNotFoundException {
    // ...
  }
}

Compliant Solution (Hiding Exceptions)

The previous noncompliant code example and compliant solution would both throw a FileNotFoundException if the password file did not exist. But suppose that the existence of the password file is considered sensitive information, and should not be thrown to potentially untrusted code?

...

class PasswordManager {

  public static void changePassword() {
    FileInputStream fin = openPasswordFile();
    if (fin == null) {
      // no password file; handle error
    }

    // test old password with password in file contents; change password
  }

  private static FileInputStream openPasswordFile() {
    final String password_file = "password";
    final FileInputStream fin[] = { null };
    AccessController.doPrivileged( new PrivilegedAction() {
        public Object run() {
          try {
            // Sensitive action; can't be done outside doPrivileged() block
            fin[0] = new FileInputStream(password_file);
          } catch (FileNotFoundException x) {
            // report to handler
          }
          return null;
        }
      });
    return fin[0];
  }
}

Risk Assessment

Returning references to sensitive resources from within a doPrivileged() block can break encapsulation and confinement. Any caller who can invoke the privileged code directly and obtain a reference to a sensitive resource or field can maliciously modify its elements.

Automated Detection

Identifying sensitive information requires assistance from the programmer; fully-automated identification of sensitive information is beyond the current state of the art.

If we had user-provided tagging of sensitive information, we could do some kind of escape analysis on the doPrivileged() blocks and perhaps prove that nothing sensitive leaks out of them. We could even use something akin to thread coloring to identify the methods that either must (or must not) be called from doPrivileged() blocks.

Related Guidelines

Bibliography

...