Page History

The Java classes used by a program are not necessarily loaded upon program startup. Many Java Virtual Machines (JVMs) load classes only when they need them.

If untrusted code is permitted to load classes, it may possess the ability to load a malicious class. This is a class that shares a fully-qualified name with a benign class that is required by trusted code. When the trusted code tries to load its benign class, the JVM provides it with the malicious class instead. As a result, if a program permits untrusted code to load classes, it must first preload any benign classes it needs. Once loaded, these benign classes cannot be replaced by untrusted code.

Noncompliant Code Example (Tomcat)

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 are able to perform sensitive operations if the trusted code invokes these APIs on their behalf.

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". 

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 utrusted code from indirectly creating the class instance. 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 object. Classloaders 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.

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 the current ClassLoader object's class loader or if the code in the current execution context has the RunTimePermission, namely "getClassLoader".

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.

...

This noncompliant code example shows a vulnerability present in several versions of the Tomcat HTTP web server (fixed in v version 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 tag library descriptor (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 certain circumstances.

Wiki MarkupThis noncompliant code example shows the declaration of a {{Digester}} instance in the {{The noncompliant code example shows the code associated with initialization 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 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.Tomcat 2009]. The code to initialize the Digester follows:

Code Block
bgColor #FFCCCC
protected static Digester webDigester = null; if (webDigester == null) { webDigester = createWebDigester(); }

The createWebDigester() method is responsible for creating the Digester. This method calls createWebXMLDigester(), which invokes the method DigesterFactory.newDigester(). This method creates the new digester instance and sets a boolean flag useContextClassLoader to true.

Code Block
bgColor #FFCCCC
// 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,
Code Block
bgColor #FFCCCC
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; }

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.

Code Block
bgColor #FFCCCC
public ClassLoader getClassLoader() { // Digester.getParser() calls this method. It is defined in class Digester public SAXParserFactory getFactory() { if (factory == null) {... if (this.useContextClassLoader) { // Uses the context class loader which was previously set // to the WebappClassLoader factoryClassLoader classLoader = SAXParserFactory.newInstance(); // Uses WebappClassLoader // ...Thread.currentThread().getContextClassLoader(); } return (factory)classloader; }

The Digester class overrides Object's getClassLoader.getParser() 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. is subsequently called by Tomcat to process web.xml and other files:

Code Block
bgColor #FFCCCC
// Digester.getParser() calls this method. It is defined in class Digester public ClassLoaderSAXParserFactory getClassLoadergetFactory() { // ... if(this.useContextClassLoaderif (factory == null) { ClassLoader classLoaderfactory = ThreadSAXParserFactory.currentThreadnewInstance().getContextClassLoader(); // Avoid Uses WebappClassLoader // ... } return classloader(factory); }

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

Compliant Solution

The underlying problem is that the newInstance() method is being invoked on behalf of a web application's class loader, the WebappClassLoader, and it loads classes before Tomcat has loaded all the classes it needs. If a web application has loaded its own Trojan javax.xml.parsers.SAXParserFactory, when Tomcat tries to access a SAXParserFactory, it accesses the Trojan SaxParserFactory installed by the web application rather than the standard Java SAXParserFactory that Tomcat depends on.

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.

Compliant Solution (Tomcat)

In this compliant solution, Tomcat initializes the SAXParserFactory when it creates the Digester. This guarantees that the SAXParserFactory is constructed 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. rather than the WebappClassLoader.

The webDigester is also declared final. This prevents any subclasses from assigning a new object reference to webDigester. (See rule OBJ10-J. Do not use public static nonfinal fields for more information.) It also prevents a race condition where another thread could access webDigester before it is fully initialized. (See rule OBJ11-J. Be wary of letting constructors throw exceptions for more information.)

protected static final Digester webDigester = nullinit();

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

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

return digester;
}

Even if the Tomcat server continues to use 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 has been set during prior initialization and cannot be replaced. Because this is a one-time setting, future attempts to change the parser are futile.

Risk Assessment

Allowing untrusted code to load classes enables untrusted code to replace benign classes with Trojan classesBypassing Securitymanager 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

...

Tool	Version	Checker	Description
Parasoft Jtest	9.5	CERT.SEC03.ACL	Do not access the class loader in a web component

Related Guidelines

Android Implementation Details

On Android, the use of DexClassLoader or PathClassLoader requires caution.

Bibliography

...

...

...

...

...

...

...

Image Added      Image Added      Image Added|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]SEC14-J. Provide sensitive mutable classes with unmodifiable wrappers      02. Platform Security (SEC)      SEC06-J. Do not use APIs that perform access checks against the immediate caller