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