Page History

Wiki MarkupThe default {{SecurityManager}} checks whether the caller of a particular method has sufficient permissions to proceed with an action. An action is nothing but a level of access, for instance, actions for {{is defined in Java's security architecture as a level of access and requires certain permissions before it can be performed. For Example, the actions for java.io.FilePermission}} are "read", " write", " execute", and "delete" \[[Sun 06|AA. Java References#Sun 06]\]. [Permission Descriptions and Risks|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html] enumerates the default permissions associated with the restricted methods. [API 2013]. The "Permission Descriptions and Risks" guide [Oracle 2011d] enumerates the default permissions and the risks associated with granting these permissions to Java code.

Sometimes, stronger restrictions than those provided by the default security manager are necessaryAt other times, stronger restrictions are necessary and custom permissions prove to be more suitable in assuming the role of privilege separators. Failure to provide custom permissions in the absence of the when no corresponding default permissions exist can lead to privilege escalation vulnerabilities wherein that enable untrusted callers can to execute restricted operations or actions.

This guideline addresses the problem of excess privileges. See SEC50-J. Avoid granting excess privileges for another approach to solving this problem.

Noncompliant Code Example

This noncompliant code example contains a privileged block that is used to perform two sensitive operationoperations: . loading a library and setting the default exception handler. Fortunately, when the default security manager is used, it does not permit loading the library unless the RuntimePermission "loadLibrary.awt" is granted in the policy file. Quite deplorably, the programmer does not guard a caller from performing the second sensitive operation - setting the default exception reporter. This security weakness can be exploited, for example, by setting the verbosity of the handler to high so that the privilege separation mechanism envisioned by the rightful observers of the log files or error messages, is broken. This example also violates the advice of SEC36-J. Guard doPrivileged blocks against untrusted invocations by using a privileged block for carrying out multiple operations at varying privilege leads.  

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

When used, the default security manager forbids the loading of the library unless the RuntimePermission loadLibrary.myLib 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 nondefault and, consequently, 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.

Compliant Solution

Define 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). By default permissions cannot be determined with actions using BasicPermission but the actions can be implemented in the subclass if required. BasicPermission is abstract even though it contains no abstract methods; it defines all the methods it extends from the Permission class. The custom defined subclass of BasicPermission class has to define two constructors to call the most appropriate (single or double argument) superclass constructor (the superclass lacks a default constructor). The two-argument constructor also accepts an action even though a basic permission does not use it. This is required for constructing permission objects from the policy file.This compliant solution then uses a security manager to check whether the caller has the requisite permission to set the handler. The code issues 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() {
        // privilegedPrivileged code
        System.loadLibrary("awtmyLib.so");

        
    // Perform some sensitive operation like setting the default exception handler
     SecurityManager sm = SystemMyExceptionReporter.getSecurityManagersetExceptionReporter(reporter); 
        if(sm != null) {return null; 
      }
    sm.checkPermission(new ExceptionReporterPermission("exc.reporter"));
        }

        // perform some sensitive operation like setting the default exception handler
  });		  
  }
}

 
final class MyExceptionReporter extends ExceptionReporter {
  public void setExceptionReporter(ExceptionReporter reporter) {
    SecurityManager sm = System.getSecurityManager();
    if(sm != null) {
      MyExceptionReporter.setExceptionReporter(reporter); sm.checkPermission(new ExceptionReporterPermission("exc.reporter"));
    }

    return// null;Proceed 
to set the exception reporter
  }
 
  //  });		  
  }... Other methods of MyExceptionReporter
}
 
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 The policy file needs to grant two permissions: ExceptionReporterPermission exc.reporter and RuntimePermission loadlibrary.myLib. The following policy file assumes that the preceding 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 the RuntimePermission "loadlibrary.awt".

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

...

By default, permissions cannot be defined to support actions using BasicPermission, but the actions can be freely implemented in the subclass ExceptionReporterPermission if required. BasicPermission is abstract even though it contains no abstract methods; it defines all the methods that it extends from the Permission class. The custom-defined subclass of the BasicPermission class must define two constructors to call the most appropriate (one- or two-argument) superclass constructor (because the superclass lacks a default constructor). The two-argument constructor also accepts an action even though a basic permission does not use it. This behavior is required for constructing permission objects from the policy file. Note that the custom-defined subclass of the BasicPermission class is declared to be final.

Applicability

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

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]\] [Class SecurityManager|http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html]
\[[Oaks 01|AA. Java References#Oaks 01]\] Chapter 5: The Access Controller, "Permissions"
\[[Policy 02|AA. Java References#Policy 02]\]
\[[Sun 06|AA. Java References#Sun 06]\] [Permission Descriptions and Risks|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html]

Bibliography

...

Image Added Image Added Image AddedSEC10-J. Do not allow the unauthorized construction of sensitive classes      00. Security (SEC)      00. Security (SEC)