The default SecurityManager
checks whether the caller of a particular method has sufficient permissions to proceed with an action. An action is a level of access, for instance, the actions for java.io.FilePermission
are "read", "write", "execute", and "delete" [[Sun 06]]. The Permission Descriptions and Risks guide [[Permissions 08]] enumerates the default permissions and the risks associated with granting these permissions.
Sometimes, stronger restrictions than those provided by the default security manager are necessary, and then custom permissions prove to be more suitable for privilege separation. Failure to provide custom permissions in the absence of the corresponding default permissions can lead to privilege escalation vulnerabilities wherein untrusted callers can execute restricted operations or actions.
Noncompliant Code Example
This noncompliant example contains a privileged block that is used to perform two sensitive operations, 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 of setting the default exception handler. This security weakness can be exploited, for example, by programming and installing a handler that reveals information that a legit handler would keep secure.
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). By default, permissions cannot be defined 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 the BasicPermission
class has to define two constructors to call the most appropriate (one- or two-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.
The compliant solution then uses a security manager to check whether the caller has the requisite permission to set the handler. The code issues 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; } }); } } 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 ones are inapplicable can leave an application open to privilege escalation vulnerabilities.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC08- J |
medium |
probable |
high |
P4 |
L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[API 06]] Class SecurityManager
[[Oaks 01]] Chapter 5: The Access Controller, "Permissions"
[[Policy 02]]
[[Sun 06]] Permission Descriptions and Risks
SEC07-J. Do not grant access to existing classes or allow the unauthorized construction of new classes in forbidden packages 01. Platform Security (SEC) SEC09-J. Prefer using SSLSockets over Sockets for secure data exchange