SEC04-J. Do not expose standard APIs that bypass Security Manager checks to untrusted code

When any method from the following table 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. (SCG 2007)

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 2005]], 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 prevented 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 delegation 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 Java SE 6 class loader delegation hierarchy shown below summarizes several cases and highlights those where security checks are bypassed:

* ICC: Intermediate caller's class loader
** COC: Class object's class loader

Care must be taken when using these APIs that trusted code does 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 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. An untrusted caller can invoke the affected APIs and bypass security checks if its 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. 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 result in vulnerabilities.

With respect to the ClassLoader object APIs, security manager checks may also 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 current ClassLoader object's class loader or if the immediate caller's class loader is the same as the current ClassLoader object's class loader or if the code in the current execution context has the getClassLoader RunTimePermission.

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

Noncompliant Code Example

This noncompliant code example accepts a class object from untrusted code, creates a new instance of the class using the permissions of the immediate caller getInstance() and returns the created instance back to untrusted code.

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

Compliant Solution

This compliant solution reduces the accessibility of getInstance() to package-private so that untrusted code cannot obtain the newly created instance.

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

Noncompliant Code Example (Tomcat)

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

The noncompliant code example shows the 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]]. The code to initialize 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.

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

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 (this.useContextClassLoader) {
    // 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) {
    factory = SAXParserFactory.newInstance(); // Uses WebappClassLoader
    // ...
  }
  return (factory);
}

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

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.

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.

Bibliography

SEC03-J. Do not allow tainted variables in doPrivileged blocks      14. Platform Security (SEC)      SEC05-J. Do not expose standard APIs that use the immediate caller's class loader instance to untrusted code