When writing a custom class loader , sometimes it is desirable to must override the getPermissions()
method. In most cases, it is recommended that the implementation must consult the default system policy by explicitly invoking the superclass's getPermissions()
method before assigning arbitrary permissions to the code source. This can be automatically handled by explicitly invoking A custom class loader that ignores the superclass's getPermissions()
method. could load untrusted classes with elevated privileges. ClassLoader
is abstract and must not be directly subclassed.
Noncompliant Code Example
This noncompliant code example shows a snippet fragment of a custom class loader that extends the class URLClassLoader
. It overrides the getPermissions()
method and but does not call the its superclass's more restrictive getPermissions()
method. Note that URLClassLoader
's getPermissions()
method calls the Policy
class's getPermissions()
method which by default, uses the global system-wide policy file to enforce access control. Consequently, a class defined using the this custom class loader has permissions that are completely independent of those specified in the system-wide systemwide policy file and in . In effect, the class's permissions override them.
Code Block | ||
---|---|---|
| ||
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = new Permissions(); // Allow exit from the VM anytime pc.add(new RuntimePermission("exitVM""exitVM")); //allow exit from the VM anytime return pc; } |
Compliant Solution
In this compliant solution, as the overridden getPermissions()
method calls super.getPermissions()
. As a result, the default system-wide systemwide security policy is also consulted applied in addition to the custom policy.
Code Block | ||
---|---|---|
| ||
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = super.getPermissions(cs); // Allow exit from the VM anytime pc.add(new RuntimePermission("exitVM""exitVM")); return pc; } |
Risk Assessment
Failure to consult the default system policy while defining a custom classloader class loader violates the tenets of defensive programming and may can result in classes defined with unintended permissions.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC10SEC07-J | high High | probable Probable | low Low | P18 | L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation Violations of this rule on the CERT website.
References
Wiki Markup |
---|
\[[API 06|AA. Java References#API 06]\] [Class ClassLoader|http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html]
\[[Oaks 01|AA. Java References#Oaks 01]\]
\[[Security 06|AA. Java References#Security 06]\] |
can be discovered with a heuristic checker in the style of FindBugs. As with all heuristic checks, achieving a low false-positive rate is essential.
Android Implementation Details
The java.security
package exists on Android for compatibility purposes only, and it should not be used.
Bibliography
...
SEC09-J. Prefer using SSLSockets over Sockets for secure data exchange 02. Platform Security (SEC) SEC30-J. Define wrappers around native methods