Page History

...

Security manager checks may 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 ClassLoader object's class loader or if the immediate caller's class loader is the same as the the ClassLoader object's class loader or if the code in the current execution context has the RunTimePermission, namely "getClassLoader".

Noncompliant Code Example

This noncompliant code example shows a vulnerability present in several versions of the Tomcat HTTP web server (fixed in v 6.0.20) that allows untrusted web applications to override the default XML parser used by the system to process web.xml, context.xml and tld files of other web applications deployed on the Tomcat instance. Consequently, untrusted web applications that install a parser can view and/or alter these files under limited circumstances.

...

Similarly, the contextDigester processing is also broken in the affected versions.

Compliant Solution

This compliant solution uses an init() method to create the webDigester. The explicit webDigester.getParser() call causes the newInstance() method to be invoked using the container's class loader instead of the context class loader (WebAppClassLoader). This is because the flag useContextClassLoader is not set at this point. The Tomcat server would still use the WebappClassLoader to create the parser instance when attempting to process the web.xml and other files, however, the explicit call to getParser() in init() ensures that the default parser is set during prior initialization. Because this is a one-time setting, future attempts to change the parser are futile.

protected static Digester webDigester = null;

protected void init() {
  if(webDigester == null){
    webDigester = createWebDigester();
    webDigester.getParser(); // Does not use the context Classloader at initialization
  }
  // ...
}

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.

Note that the Class.newInstance() method requires the class to contain a no-argument constructor. If this requirement is not satisfied, a runtime exception results, which indirectly prevents a security breach.

Risk Assessment

Bypassing Securitymanager checks may seriously compromise the security of a Java application.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Gong 03|AA. Java References#Gong 03]\] Section 4.3.2, Class Loader Delegation Hierarchy
\[[SCG 07|AA. Java References#SCG 07]\] Guideline 6-2 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader
\[[Tomcat 09|AA. Java References#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 08|AA. Java References#CVE 08]\] [CVE-2009-0783|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0783]

...