Page History

...

Sometimes, stronger restrictions than those provided by the default security manager are necessary. Custom permissions prove to be more suitable for privilege separation in such cases. Failure to provide custom permissions when no corresponding default permissions exist can lead to privilege escalation vulnerabilities that enable untrusted callers to execute restricted operations or actions.

Noncompliant Code Example

This noncompliant code example contains a privileged block that is used to perform two sensitive operations, loading a library and setting the default exception handler. When used, the default security manager does not permit the loading of the library unless the RuntimePermission loadLibrary.awt is granted in the policy file. However, the security manager does not automatically guard a caller from performing the second sensitive operation of setting the default exception handler because the permission for this operation is not nondefault and consequently is unavailable. This security weakness can be exploited, for example, by programming and installing an exception handler that reveals information that a legitimate handler would filter out.

class LoadLibrary {
  private void loadLibrary() {
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
        // privileged code
        System.loadLibrary("awt");
        // perform some sensitive operation like setting the default exception handler
        MyExceptionReporter.setExceptionReporter(reporter); 
        return null; 
      }
    });		  
  }
}

Compliant Solution

This compliant solution defines a custom permission ExceptionReporterPermission with target exc.reporter to prohibit illegitimate callers from setting the default exception handler. This can be achieved by subclassing BasicPermission, which allows binary-style permissions (either allow or disallow).

...

The compliant solution then uses a security manager to check whether the caller has the requisite permission to set the handler. The code throws a SecurityException if the check fails. The custom permission class ExceptionReporterPermission is also defined with the two required constructors.

class LoadLibrary {
  private void loadLibrary() {
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
        // privileged code
        System.loadLibrary("awt");
      
        SecurityManager sm = System.getSecurityManager();
        if(sm != null) {
          sm.checkPermission(new ExceptionReporterPermission("exc.reporter"));
        }

        // perform some sensitive operation like setting the default exception handler
        MyExceptionReporter.setExceptionReporter(reporter); 
        return null; 
      }
    });		  
  }
}

final class ExceptionReporterPermission extends BasicPermission {
  public ExceptionReporterPermission(String permName) {
    super(permName);
  }

  // Even though the actions parameter is ignored, this constructor has to be defined
  public ExceptionReporterPermission(String permName, String actions) {
    super(permName, actions);
  }
}

Assuming that the above sources reside in the c:\package directory on a Windows-based system, for example, the policy file needs to grant two permissions, ExceptionReporterPermission exc.reporter and RuntimePermission loadlibrary.awt.

grant codeBase "file:c:\\package" {  // For *nix, file:${user.home}/package/ 
  permission ExceptionReporterPermission "exc.reporter";
  permission java.lang.RuntimePermission "loadLibrary.awt"; 
};

Risk Assessment

Running Java code without defining custom permissions where default permissions are inapplicable can leave an application open to privilege escalation vulnerabilities.

Automated Detection

TODOAutomated detection is not feasible.

Related Vulnerabilities

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

Related Guidelines

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

Bibliography

[API 2006] Class SecurityManager
[Oaks 2001] Chapter 5: The Access Controller, "Permissions"
[Policy 2002]
[Sun 2006] Permission Descriptions and Risks

...