Class loaders allow an application to dynamically extend a Java application at runtime by loading classes. For The JVM tracks, for each class it loads, the JVM keeps track of which loaded, which specific class loader loaded performed the classload. When a loaded class first refers to another class, the virtual machine requests that the referenced class to be loaded by the same class loader that originally loaded loader used to load the referencing class.
Java's class loader architecture controls interaction between code loaded from different sources by allowing the use of different class loaders. This separation of class loaders is fundamental to the separation of code and ; it prevents malicious code from gaining access to and subverting trusted code. Hence, it is important to preserve this separation. A class loader that loads untrusted code should not interact must be prevented from interacting with trusted code that invokes any of the methods from the following table:
...
The trusted code's class loader allows these methods to be invoked, although an untrusted code's class loader may lack these privileges. However, when the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code has gains visibility to the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation; consequently, the untrusted code would be unable to observe members or to invoke methods belonging to the trusted code.
A problem arises because the class loader delegation model is imperative fundamental to many Java implementations and frameworks. So the best advice is to avoid exposing the methods listed above to untrusted code.
Consider, for example, an attack scenario where untrusted code is attempting to load a privileged class. If its class loader is permitted to delegate the class loading to a trusted class's class loader, then privilege escalation can occur, because the untrusted code's class loader may lack permission to load the requested privileged class on its own. Furthermore, if the trusted code accepts tainted inputs, the trusted code's class loader could load additional privileged — or even malicious — classes on behalf of the untrusted code.
Classes that have the same defining class loader will exist in the same namespace but they can have different privileges, depending on the security policy. Security vulnerabilities can arise when trusted code coexists with untrusted code (or less-privileged code) that was loaded by the same class loader. In this case, the untrusted (or less-privileged) code can freely access members of the trusted code according to their declared accessibility. When the trusted code uses any of the tabulated APIs, no it bypasses security manager checks are carried out (with the exception of loadLibrary() and load()).
A security-sensitive class loader typically employs the security manager to enforce a security policy before loading new classes. For example, the applet class loader ensures that an applet cannot directly invoke methods of classes present in the com.sun.* package. A security manager check ensures that specific actions are allowed or denied depending on the privileges of all of the caller methods on the call stack (the privileges are associated with the code source that encompasses the class). A security manager complements, rather than superseding, the security offered by the class loader architecture and does not supersede it. Consequently, APIs that perform security manager checks may still violate this guideline at the class loader level when exposed to untrusted callers.
With the exception of the loadLibrary() and load() methods, the tabulated methods do not fail to perform any security manager checks. The loadLibrary() and load() APIs are typically used from within a doPrivileged block and, ; in that case, unprivileged callers can directly invoke them without requiring any special permissions. That means that Consequently, the security manager checks are curtailed at the immediate caller and so ; the security manager fails to examine the entire call stack is not examined, resulting in no and so fails to provide enhanced security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may expose vulnerabilities.
...
In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block. This is insecure because a library can be loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load a library even though it lacks sufficient permissions to do so directly. After loading the library, untrusted code can call native methods on it if the from the library if those methods are accessible. This is possible because the doPrivileged block stops security manager checks being applied to callers further up the execution chain.
...
Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability. However, but after loading an additional unsafe library, an attacker can easily exploit the safe library if it contains other vulnerabilities. Moreover, nonnative libraries often use doPrivileged blocks, making them lucrative attractive targets.
Compliant Solution
...
It is permissible to use APIs that do not use the immediate caller's class loader instance. For example, the three-argument java.lang.Class.forName() method requires an explicit argument that specifies the class loader instance to use. Do not use the immediate caller's class loader as the third argument if when instances must be returned to untrusted code.
...