Page History

When any method from the 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. 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()). If a security manager is present, untrusted code that does not have the permissions to use the API directly is also denied 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 delgation 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

...

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 05|AA. Java References#JLS 05]\] section 4.3.2 "The Class {{Object}}": "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 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 delgation 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.

The first ten methods shown in the table can be invoked on a Class object. Care must be taken when using these APIs. In particular, trusted code should 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 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). Similarly, instances of trusted Class objects should not be returned to untrusted code. Security vulnerabilities can arise if the untrusted code's class loader is the same as or the delegation ancestor of the trusted code's class loader.

The table also shows APIs that use the ClassLoader class object. Classloaders 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 vulnerabilities.

...

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.newDigester()}} 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);
}

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.

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.

...

This compliant solution uses an init() method to create the webDigester.

protected static Digester webDigester = null;

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

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.

...

...

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.

...