SEC21-J. Remove superfluous code from privileged blocks

Programs must comply with the principle of least privilege not only by providing privileged blocks with the minimum permissions required for correct operation, but also by ensuring that privileged blocks contain only those operations that require the increased privileges. Superfluous code contained within a privileged block necessarily operates with the privileges of that block; this increases the potential attack surface exposed to an adversary. Consequently, privileged blocks are forbidden to contain superfluous code.

Noncompliant Code Example

This noncompliant code example shows a changePassword() method that attempts to open a password file using a doPrivileged block. The doPrivileged block also contains logic that operates on the file and a superfluous System.loadLibrary() call.

public void changePassword() {
  final FileInputStream f[] = { null };

  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() {
      try {
        String passwordFile = System.getProperty("user.dir") + File.separator
            + "PasswordFileName";
        f[0] = new FileInputStream(passwordFile);                                                     
        // Operate on the file ...
        System.loadLibrary("LibName");
      } catch (FileNotFoundException cnf) {
        // Forward to handler
      }
      return null;
    }
  }); // end of doPrivileged()
}

This is a violation of the principle of least privilege because a caller who does not have the required privileges can indirectly load the library provided the security policy allows doing so. This transfers the burden of ensuring security to the administrator who implements the security policy.

Compliant Solution

This compliant solution moves the call to System.loadLibrary() outside the doPrivileged() block. Any operations on the file descriptor f[0] must also occur outside the privileged block to make it easier to audit privileged code. However, f[0] should not leak out to untrusted code (see [SEC02-J. Do not allow doPrivileged() blocks to leak sensitive information outside a trust boundary]). Therefore, the "operations on the file" must not allow f[0] to escape out of changePassword(). Minimizing the amount of code that requires elevated privileges eases the necessary task of auditing privileged code.

public void changePassword() {
  final FileInputStream f[] = { null };

  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() {
      try {
        String passwordFile = System.getProperty("user.dir") + File.separator
            + "PasswordFileName";
        f[0] = new FileInputStream(passwordFile);                                                     
      } catch (FileNotFoundException cnf) {
        // Forward to handler
      }
      return null;
    }
  });  // end of doPrivileged()
  // Operations on the file using handle f[0]
  // while ensuring that the f[0] reference     
  // remains contained within changePassword()
  System.loadLibrary("LibName");
}

Risk Assessment

Failure to follow the principle of least privilege can lead to privilege escalation.

Automated Detection

Automated checking is clearly not possible in the general case. We might be able to do something with escape analysis to check that we are not leaking privileged data provided that privileged data is marked by the user, and even that would be difficult.

Related Vulnerabilities

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

Related Guidelines

Bibliography

SEC19-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar      14. Platform Security (SEC)      15. Runtime Environment (ENV)