...
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 wherein untrusted callers can 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. This is because the permission for this operation is not non-default and consequently, unavailable. This security weakness can be exploited, for example, by programming and installing an exception handler that reveals information that a legit handler would filter out.
Code Block | ||
---|---|---|
| ||
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).
...
Code Block |
---|
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
Wiki Markup |
---|
\[[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] |
...