Security manager checks may be allowed to get bypassed depending on the immediate caller's class loader. When an API (see table below) is invoked on a class object, a comparison is run between the immediate caller's class loader and that of the class object. The class object is the object on which an API is invoked. For instance, in the presence of a security manager, the getSystemClassLoader
and getParent
methods succeed only if the caller's class loader is the delegation ancestor of the current class loader or if the caller's class loader is the same as the current one or if the code in the current execution context has the RunTimePermission
, namely "getClassLoader
".
APIs capable of bypassing SecurityManager's checks |
---|
java.lang.Class.newInstance |
java.lang.Class.getClassLoader |
java.lang.Class.getClasses |
java.lang.Class.getField(s) |
java.lang.Class.getMethod(s) |
java.lang.Class.getConstructor(s) |
java.lang.Class.getDeclaredClasses |
java.lang.Class.getDeclaredField(s) |
java.lang.Class.getDeclaredMethod(s) |
java.lang.Class.getDeclaredConstructor(s) |
java.lang.ClassLoader.getParent |
java.lang.ClassLoader.getSystemClassLoader |
java.lang.Thread.getContextClassLoader |
Noncompliant Code Example
The createInstance
method is the immediate caller of java.lang.Class.newInstance
<TO BE CONFIRMED> in this noncompliant example. The newInstance
method is being invoked on the dateClass
class object. The issue is that the untrustedCode
method can trigger the instantiation of a new class even though it should not have the permission to do so. This behavior is not caught by the security manager.
import java.util.Date; public class ExceptionExample { public static void untrustedCode() { Date now = new Date(); Class<?> dateClass = now.getClass(); createInstance(dateClass); } public static void createInstance(Class<?> dateClass) { try { // Create another Date object using the Date Class Object o = dateClass.newInstance(); if (o instanceof Date) { Date d = (Date)o; System.out.println("The time is: " + d.toString()); } } catch (InstantiationException ie) { System.out.println(ie.toString()); } catch (IllegalAccessException lae) { System.out.println(iae.toString()); } } }
Compliant Solution
Do not accept Class
, ClassLoader
or Thread
instances from untrusted code. If inevitable, safely acquire these instances by ensuring they come from trusted sources. Additionally, make sure to discard tainted inputs from untrusted code. Likewise, objects returned by the affected methods should not be propagated back to the untrusted code.
Risk Assessment
Bypassing Securitymanager
checks may seriously compromise the security of a Java application.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC02-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
[[Gong 03]] Section 4.3.2, Class Loader Delegation Hierarchy
[[SCG 07]] Guideline 6-2 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader
SEC01-J. Be careful using doPrivileged 00. Security (SEC) SEC03-J. Beware of standard APIs that may use the immediate caller's class loader instance