Page History

...

public class Trusted {
  Object getInstance(Class<?> c) throws InstantiationException, IllegalAccessException {
    return c.newInstance();
  }
}

Noncompliant Code Example (Tomcat)

This noncompliant code example shows illustrates 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 could view and/or alter these files under limited circumstances.

ThisThe noncompliant code example shows the declaration code associated with initialiation of a new {{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 2009|AA. Bibliography#Tomcat 09]\].  The code to methodinitialize call chain can be traced as the following:the {{Digester}} follows:

protected static Digester webDigester = null;

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

The createWebDigester() method is responsible for creating the Digester. This method internally calls createWebXMLDigester()

...

, which invokes the method DigesterFactory.newDigester()

...

. Thie method creates the new digester instance and sets a boolean flag useContextClassLoader to true.

...

protected static Digester webDigester = null;

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

// This method exists in the class DigesterFactory and is called by // 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

The useContextClassLoader flag is used by Digester to decide which ClassLoader to use when loading new classes. When true, it uses the WebappClassLoader, which is untrusted, because it loads whatever classes are requested by various web applications.

public ClassLoader getClassLoader() {
  if (factory == null// ...
  if (this.useContextClassLoader) {
    factory = SAXParserFactory.newInstance(); // Uses WebappClassLoader
    // ...
  }
  return (factory);
}

...

// Uses the context class loader which was previously set to the WebappClassLoader
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
  }
  return classloader;
}

Later, the Digester.getParser() method is internally called by Tomcat to process

...

web.xml and other files

...

:

// Digester.getParser() calls this method. It is defined in class Digester
public SAXParserFactory getFactory() {
  if (factory == null

The underlying problem is that the newInstance() method is being invoked on behalf of an untrusted web application's class loader.

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

public ClassLoader getClassLoader() {
  // ...
  if(this.useContextClassLoader) {
      factory = SAXParserFactory.newInstance(); // Uses the context class loader which was previously set to the WebappClassLoader
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader();// ...
  }
  return classloader(factory);
}

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

Compliant Solution

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 underlying problem is that the newInstance() method is being invoked on behalf of an untrusted web application's class loader, the WebappClassLoader. If a web application has previously loaded its own javax.xml.parsers.SAXParserFactory, then the web application's SAXParserFactory will be returned by getFactory(), instead of the standard SAXParserFactory used by Tomcat.

Compliant Solution (Tomcat)

This compliant solution initializes the SAXParserFactory when it creates the Digester. This guarantees that the SAXParserFactory is constructed using the container's class loader, instead of the WebappClassLoader.

The webDigester is also marked final. This prevents any subclasses from assigning a new object reference to webDigester. See OBJ04-J. Do not use public static non-final variables for more info. It also prevents a race condition where another thread could access webDigester before it is fully initialized; see OBJ05-J. Prevent access to partially initialized objects for more info.

protected static final Digester webDigester = init();

protected Digester init() {
  Digester digester = createWebDigester();
  digester.getParser(); // Does not use the context Classloader at initialization, so safe
  return digester;
  // ...
}

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 not (??) 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.

...

...