Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

Code Block
bgColor#FFCCCC
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.

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

Noncompliant Code Example

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

...

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

Compliant Solution

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

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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC04-J

high

probable

medium

P12

L1

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Bibliography

Wiki Markup
\[[CVE 2008|AA. Bibliography#CVE 08]\] [CVE-2009-0783|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0783]
\[[Gong 2003|AA. Bibliography#Gong 03]\] Section 4.3.2, Class Loader Delegation Hierarchy
\[[JLS 2005|AA. Bibliography#JLS 05]\] Section 4.3.2, "The Class {{Object}}"
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 6-2 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader
\[[Tomcat 2009|AA. Bibliography#Tomcat 09]\] [Bug ID 29936|https://issues.apache.org/bugzilla/show_bug.cgi?id=29936], API Class {{org.apache.tomcat.util.digester.Digester}}, [Security fix in v 6.0.20|http://tomcat.apache.org/security-6.html]

...