Class loaders allow an application to dynamically extend a Java application at runtime by loading classes. For each class it loads, the JVM keeps track of which class loader loaded the class. When a loaded class first refers to another class, the virtual machine requests the referenced class from to be loaded by the same class loader that originally loaded the referencing class.
...
Methods |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
The invocation of these methods is allowed by the trusted code's class loader allows these methods to be invoked, however, an untrusted code's class loader may lack these privileges. When the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code has visibility to the trusted code according to the declared visibility of 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. Such a delegation model is imperative to many Java implementations and frameworks so the best advice is to avoid exposing these methods to untrusted code.
Consider, for example, an attack scenario where untrusted code is attempting to load a privileged class. Its If its class loader is permitted to delegate the class loading to the a trusted class's class loader. This can result in , then privilege escalation can occur, because the untrusted code's class loader may lack permission to load the requested privileged class on its own. FurtherFurthermore, 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 may 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 defining class loader. In this case, the untrusted 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 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 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 of the loadLibrary() and load() methods, the tabulated methods do not 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 the security manager checks are curtailed at the immediate caller and so the entire call stack is not examined, resulting in no enhanced security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may expose vulnerabilities.
...