Page History

...

Classloaders facilitate isolation of trusted components from untrusted ones. They also ensure that the untrusted components do not interfere with each. 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 can expose security vulnerabilities.

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.

This noncompliant code example shows the declaration of a {{Digester}} instance in the {{org.apache.catalina.startup.ContextConfig}} class. "A {{Digester}} processes an XML input stream by matching a series of element nesting patterns to execute Rules that have been added prior to the start of parsing" \[[Tomcat 09|AA. Java References#Tomcat 09]\]. The {{createWebDigester()}} method is responsible for creating the {{Digester}}. This method internally calls {{createWebXMLDigester()}} which requests the method {{DigesterFactory.newDister()}} to create a new digester instance and sets a {{boolean}} flag {{useContextClassLoader}} to {{true}}. This means that the context class loader, in this case the _WebappClassLoader_, is used to create the digester. Later, when the {{Digester.getParser()}} method is internally called by Tomcat to process the web.xml and other files, according to the search rules, the parser installed by the untrusted web application is preferred, otherwise, the default parser is used. The underlying problem is that the {{newInstance()}} method is being invoked on behalf of an untrusted web application's classloader.

protected static Digester webDigester = null;

if(webDigester == null){
  webDigester = createWebDigester();
}

// This method exists in the class DigesterFactory and is called by ContextConfig.createWebXmlDigester() 
// which is in turn called by ContextConfig.createWebDigester()
// webDigester finally contains the value of digester defined in this method
public static Digester newDigester(boolean xmlValidation, boolean xmlNamespaceAware, RuleSet rule) {
  Digester digester = new Digester();
  // ...
  digester.setUseContextClassLoader(true);
  // ...
  return digester;
}

// Digester.getParser() calls this method. It is defined in class Digester
public SAXParserFactory getFactory() {
  if (factory == null) {
    factory = SAXParserFactory.newInstance(); // Uses WebappClassLoader
    // ...
  }
  return (factory);
}

The Digester class overrides Object's getClassLoader() method and this is used to obtain the classloader to load the class, depending on the value of the flag useContextClassLoader. A partial implementation is shown below.

public ClassLoader getClassLoader() {
  // ...
  if(this.useContextClassLoader) {
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); 
  }
  return classloader;
}

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
  }
  // ...
}

Noncompliant Code 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.

...

A related issue is described in SEC03-J. Do not use APIs that perform access checks against the immediate caller.

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.

...