When any method from the following table shown below is invoked on a Class, ClassLoader or Thread object, a comparison is run between the method's immediate caller's class loader and that of the object on which the method is invoked.
...
| Wiki Markup |
|---|
As an example of what constitutes the immediate caller and the object, consider the method {{java.lang.Class.newInstance()}}. Here, the immediate caller is the class that contains this method call whereas the object on which the {{newInstance()}} method is being invoked is referred to as the {{Class}} object ({{classObjectName.newInstance()}}). According to the Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], Section 4.3.2, "The Class {{Object}}": "The the method {{getClass}} returns the {{Class}} object that represents the class of the object." |
If a security manager is present, untrusted code that does not have the permissions to use the API directly is disallowed prevented from indirectly using trusted code containing the API call , to perform the operation. However, the security manager checks are bypassed if the class loader of the immediate caller is the same as or the delegation ancestor of the class loader of the object on which the API is invoked. Consequently, untrusted callers who do not have the required permissions but are capable of passing the class loader check , are able to perform sensitive operations if the trusted code invokes these APIs on their behalf.
...
Immediate Caller | ICC* | Class Object | COC** | Classloader Class Loader Check | Security Check |
|---|---|---|---|---|---|
C1 | A | C2, C3, C4, C5 | Application, B, C | A is not a delegation ancestor of Application, B or C | Yes |
C2 | Application | C1 | A | Application is not a delegation ancestor of A | Yes |
C2 | Application | C3, C4, C5 | B and C | Application is a delegation ancestor of B and C | No |
C3 | B | C4 | B | The class loader is same for C3 and C4 (B) | No |
C4 | B | C3 | B | The class loader is same for C4 and C3 (B) | No |
C5 | C | C1, C2, C3, C4 | Application, A, B, C | C is not a delegation ancestor of Application, A, B or C | Yes |
* ICC: Intermediate caller's classloaderclass loader
** COC: Class object's classloaderclass loader
Care must be taken when using these APIs . In particular, that trusted code should does not accept Class objects from untrusted code for further use. For example, if trusted code is loaded by the bootstrap class loader, it can create an instance of a sensitive system class by using the newInstance() method on the Class object. If the method that creates the instance is visible to untrusted code, no security manager checks are carried out to prohibit the untrusted code from indirectly creating the class instance (untrusted code must pass the class loader comparison check).
...
The table also shows APIs that use the ClassLoader class object. Class loaders facilitate isolation of trusted components from untrusted ones. They also ensure that the untrusted components do not interfere with each other. The proper choice of the class loader to load a class is of utmost importance. Using less trusted class loaders for performing operations of sensitive nature in trusted code can expose security result in vulnerabilities.
With respect to the ClassLoader object APIs, security manager checks may also get bypassed depending on the immediate caller's class loader. Consider for instance, the ClassLoader.getSystemClassLoader() and ClassLoader.getParent() methods that operate on a ClassLoader object. In the presence of a security manager, these methods succeed only if the immediate caller's class loader is the delegation ancestor of the current ClassLoader object's class loader or if the immediate caller's class loader is the same as the current ClassLoader object's class loader or if the code in the current execution context has the getClassLoader RunTimePermission, namely "getClassLoader".
As noted earlier, untrusted code can bypass the security checks if its classloader class loader is either the same or a delegation ancestor of the trusted code's class loader. Consequently, care must be taken while specifying the parent of a trusted classloaderclass loader. Likewise, trusted code should not use a classloader class loader instance supplied by untrusted code. For instance, a class loader instance obtained from untrusted code should not be used to load a trusted class that performs some sensitive operation. Also, a trusted classloader class loader that performs security sensitive operations should never be made available to untrusted code by returning its instance.
...
The underlying problem is that the newInstance() method is being invoked on behalf of an untrusted web application's classloaderclass loader.
The Digester class overrides Object's getClassLoader() method and this is used to obtain the classloader class loader to load the class, depending on the value of the flag useContextClassLoader. A partial implementation is shown below.
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
| Wiki Markup |
|---|
\[[JLS 2005|AA. Bibliography#JLS 05]\] Section 4.3.2, "The Class {{Object}}"
\[[Gong 2003|AA. Bibliography#Gong 03]\] Section 4.3.2, Class Loader Delegation Hierarchy
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 6-2 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader
\[[Tomcat 2009|AA. Bibliography#Tomcat 09]\] [Bug ID 29936|https://issues.apache.org/bugzilla/show_bug.cgi?id=29936], API Class {{org.apache.tomcat.util.digester.Digester}}, [Security fix in v 6.0.20|http://tomcat.apache.org/security-6.html]
\[[CVE 2008|AA. Bibliography#CVE 08]\] [CVE-2009-0783|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0783] |
...