...
If untrusted code is permitted to load classes, it may possess the ability to load sensitive classes required by trusted code. If the trusted code has not already loaded these classes, attempts to subsequently do so may result in untrusted classes being substituted for the sensitive classes. As a result, if a program permits untrusted code to load classes, it must first preload any sensitive classes it needs. Once properly loaded, these sensitive classes cannot be replaced by untrusted code.
Noncompliant Code Example (Tomcat)
This noncompliant code example shows a vulnerability present in several versions of the Tomcat HTTP web server (fixed in 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 tag library descriptor (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 certain circumstances.
...
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 javax.xml.parsers.SAXParserFactory, then when Tomcat tries to access a SAXParserFactory, it will access the incorrect SaxParserFactory used by the web app, rather than the standard Java SAXParserFactory that it depends on.
Compliant Solution (Tomcat)
In this compliant solution, Tomcat initializes the SAXParserFactory when it creates the Digester. This guarantees that the SAXParserFactory is constructed using the container's class loader, rather than the WebappClassLoader.
...
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
Allowing untrusted code to load classes enables untrusted code to replace benign classes with malicious classes.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SEC04 SEC03-J | high | probable | medium | P12 | L1 |
Related Guidelines
Secure Coding Guidelines for the Java Programming Language, Version 3.0 | Guideline 6-3 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="de60f2a625c48819-fb9b7ee6-4afd44b3-9b1e943e-e3e2cf71da92ed9e0ad607ea"><ac:plain-text-body><![CDATA[ | [[CVE 2008 | AA. Bibliography#CVE 08]] | [CVE-2009-0783 | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0783] | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="527919cac57e5831-6ba1e951-48b04db4-b611a8ca-e1a297492e659a481d72c450"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | Section 4.3.2, Class Loader Delegation Hierarchy | ]]></ac:plain-text-body></ac:structured-macro> | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b8d48dc1f51f0033-d8089ba7-446d47ff-a011969a-59041c952c4c2bba1d8a053f"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | Section 4.3.2, "The Class | ]]></ac:plain-text-body></ac:structured-macro> | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="58b2bc9b2aed5d41-185e61f7-447a442d-86cabe06-5ff64dacc09ec6fd3490eeb1"><ac:plain-text-body><![CDATA[ | [[Tomcat 2009 | AA. Bibliography#Tomcat 09]] | [Bug ID 29936 | https://issues.apache.org/bugzilla/show_bug.cgi?id=29936], API Class | http://tomcat.apache.org/security-6.html] | ]]></ac:plain-text-body></ac:structured-macro> |
...