Page History

...

Untrusted code can bypass the security checks if its classloader is either the same or a delegation ancestor of the current class loader. Consequently, care must be taken while specifying the parent of a trusted classloader. Likewise, trusted code should not use a classloader 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 that performs security sensitive operations should never be made available to untrusted code by returning its instance.

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 WebAppClassLoader. This is because the flag useContextClassLoader is set during initialization which captures the container's class loader at that time to define the Digester (the context class loader is the container's class loader at this point). Later, even if the Tomcat server still uses the WebappClassLoader to create the parser instance when attempting to process the web.xml and other files, the explicit call to getParser() in init() ensures that the default parser is set during prior initialization and is impossible to replace. 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 Security manager 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]

...