...
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 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:
Immediate Caller | ICC* | Class Object | COC** | Classloader Check | Security Check |
|---|---|---|---|---|---|
C1 | A | C2, C3, C4, C5 | Application, B, C | A is not a delegation ancestor of Application, B or C | Yes |
C2 | Application | C3, C4, C5 | B and C | Application is a delegation ancestor of B and C | No |
C3 | B | C4 | B | The class loader is same for C3 and C4 (B) | No |
C4 | B | C3 | B | The class loader is same for C4 and C3 (B) | No |
C5 | C | C1, C2, C3, C4 | Application, A, B, C | C is not a delegation ancestor of Application, A, B or C | Yes |
* ICC: Intermediate caller's classloader
** COC: Class object's classloader
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.
...
| Wiki Markup |
|---|
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 {{ method call chain can be traced as: |
- The
createWebDigester()
...
- method
...
- is
...
- responsible
...
- for
...
- creating
...
- the
...
Digester
...
- .
...
- This
...
- method
...
- internally
...
- calls
createWebXMLDigester(). - The method
createWebXMLDigester()
...
- 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.
...
| Code Block | ||
|---|---|---|
| ||
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.
...