Page History

Class loaders's 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 the same class loader that originally loaded the referencing class.  Classes loaded by different class  loaders are in different name-spaces and cannot gain access to each other unless the application explicitly allows it. By default, classes can only see other classes that were loaded by the same class loader.

Java's class loader architecture to control interaction between code loaded from different sources by using different class loaders to load code from different sources.  This prevents malicious code from gaining access to and subverting trusted code.                                                     

A class loader that loads untrusted code should not interact with trusted code that invokes any of the methods from the following table:

The classloader architecture is key when it comes to preventing untrusted code from impersonating trusted code and isolating the two from each other. Most software systems use different classloaders to load untrusted and trusted code sources to provide the isolation guarantees.

A classloader that loads untrusted code should be forbidden from interacting with trusted code that invokes the following API methods.

The invocation of these API methods is allowed by the trusted code's classloaderclass loader, however, untrusted code's classloader class loader may lack these privileges. Failure to comply with this guideline may result in compromise of the trust boundary between the trusted and untrusted code. 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.

...

A security sensitive class loader typically employs the security manager to enforce a security policy. 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 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 classloader 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 loadLibrary() and load() methods, the tabulated APIs methods do not perform any security manager checks. Because the loadLibrary and load APIs are typically used from within a doPrivileged block, 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 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 also expose vulnerabilities.

...

This guideline is an instance of SEC04-J. Protect sensitive operations with security manager checks. Many examples also violate SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary.

Noncompliant Code Example

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. After loading the library, untrusted code can call native methods on it if the 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, 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 targets.

Compliant Solution

This compliant solution reduces the accessibility of method load() from public to private. Consequently, untrusted callers are prohibited from loading the awt library. Also, the name of the library is hard-coded to reject the possibility of tainted values.

private void load() {
  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() { 
      System.loadLibrary("awt");
      return null; 
    }
  });
}

Noncompliant Code Example

A method that passes untrusted inputs to the Class.forName() method might permit an attacker to access classes with escalated privileges. The single argument Class.forName() method is another API method that uses its immediate caller's class loader to load a requested class. Untrusted code can misuse this API to indirectly manufacture classes that have the same privileges as those of the attacker's immediate caller.

public Class loadClass(String className) {
  // className may be the name of a privileged or even a malicious class
  return Class.forName(className);
}

Compliant Solution (Hardcoded Name)

This compliant solution hard-codes the class's name.

public Class loadClass() {
  return Class.forName("Foo");
}

Noncompliant Code Example

This noncompliant code example returns an instance of java.sql.Connection from trusted to untrusted code. Untrusted code that lacks the permissions required to create a SQL connection can bypass these restrictions by using the acquired instance directly.

public Connection getConnection(String url, String username, String password) {
  // ...
  return DriverManager.getConnection(url, username, password);
}

Compliant Solution

The getConnection() method is unsafe because it uses the url to indicate a class to be loaded; this class serves as the database driver. This compliant solution prevents a malicious user from supplying their own URL to the database connection; thereby limiting their ability to load untrusted drivers.

private String url = // hardwired value

public Connection getConnection(String username, String password) {
  // ...
  return DriverManager.getConnection(this.url, username, password);
}

Applicability

Allowing untrusted code to carry out actions using the immediate caller's class loader may allow the untrusted code to execute with the same privileges as the immediate caller.

...

public static Class forName(String name,
                            boolean initialize,
                            ClassLoader  ClassLoader loader) /* explicitly specify the class loader to use */
                     throws ClassNotFoundException

Risk Assessment

Related Guidelines

Bibliography

[API 2011] Class ClassLoader

...