...

Because the java.lang.reflect.Field.setAccessible() and getAccessible() methods are used to instruct the Java Virtual Machine (JVM) to override the language access checks, they perform standard (and more restrictive) security manager checks and consequently lack the vulnerability described by this guideline. Nevertheless, these methods should also be used with extreme caution. The remaining set* and get* field reflection methods perform only the language access checks and are consequently vulnerable.

Class Loaders

Class loaders allow a Java application to be dynamically extended at runtime by loading additional classes. For each class that is loaded, the JVM tracks the class loader that was used to load the class. When a loaded class first refers to another class, the virtual machine requests that the referenced class be loaded by the same class loader that was 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: it prevents malicious code from gaining access to and subverting trusted code.

...

This guideline is similar to SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes. 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.

...

Nonnative library code can also be susceptible to related security flaws. Suppose there exists a library that contains a vulnerability that is not directly exposed, perhaps because it lies in an unused method. Loading this library may not directly expose a vulnerability. However, an attacker could then load an additional library that exploits the first library's vulnerability. Moreover, nonnative libraries often use doPrivileged blocks, making them attractive targets.

Compliant Solution

This compliant solution hard codes the name of the library to prevent the possibility of tainted values. It also reduces the accessibility of the load() method from public to private. Consequently, untrusted callers are prohibited from loading the awt library. 

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

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. The getConnection() method is unsafe because it uses the url argument to indicate a class to be loaded; this class serves as the database driver.

Compliant Solution

This compliant solution prevents malicious users 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);
}

Noncompliant Code Example (CERT Vulnerability 636312)

CERT Vulnerability Note VU#636312 describes a vulnerability in Java 1.7.0 update 6 that was widely exploited in August 2012. The exploit actually used two vulnerabilities; the other one is described in SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields.)

...

Although this method is called in the context of an applet, it uses Class.forName() to obtain the requested class. Class.forName() delegates the search to the calling method's class loader. In this case, the calling class (com.sun.beans.finder.ClassFinder) is part of core Java, so the trusted class loader is used in place of the more restrictive applet class loader, and the trusted class loader loads the class, unaware that it is acting on behalf of malicious code.

Compliant Solution (CVE-2012-4681)

Oracle mitigated this vulnerability in Java 1.7.0 update 7 by patching the com.sun.beans.finder.ClassFinder.findClass() method. The checkPackageAccess() method checks the entire call stack to ensure that Class.forName(), in this instance only, fetches classes only on behalf of trusted methods.

public static Class<?> findClass(String name) 
   throws ClassNotFoundException {
  checkPackageAccess(name);
  try {
    ClassLoader loader = Thread.currentThread().getContextClassLoader();
    if (loader == null) {
      // Can be null in IE (see 6204697)
      loader = ClassLoader.getSystemClassLoader();
    }
    if (loader != null) {
      return Class.forName(name, false, loader);
    }

  } catch (ClassNotFoundException exception) {
    // Use current class loader instead
  } catch (SecurityException exception) {
    // Use current class loader instead
  }
  return Class.forName(name);
}

Noncompliant Code Example (CVE-2013-0422)

Java 1.7.0 update 10 was widely exploited in January 2013 because of several vulnerabilities. One vulnerability in the MBeanInstantiator class granted unprivileged code the ability to access any class regardless of the current security policy or accessibility rules. The MBeanInstantiator.findClass() method could be invoked with any string and would attempt to return the Class object named after the string. This method delegated its work to the loadClass() method, whose source code is shown here:

...

This method delegates the task of dynamically loading the specified class to the Class.forName() method, which delegates the work to its calling method's class loader. Because the calling method is MBeanInstantiator.loadClass(), the core class loader is used, which provides no security checks.

Compliant Solution (CVE-2013-0422)

Oracle mitigated this vulnerability in Java 1.7.0 update 11 by adding an access check to the MBeanInstantiator.loadClass() method. This access check ensures that the caller is permitted to access the class being sought:

// ...
    if (className == null) {
        throw new RuntimeOperationsException(new
            IllegalArgumentException("The class name cannot be null"),
                          "Exception occurred during object instantiation");
    }
    ReflectUtil.checkPackageAccess(className);
    try {
        if (loader == null)
// ...

Applicability

Allowing untrusted code to invoke methods with reduced-security checks can result in privilege escalation. Likewise, allowing untrusted code to perform actions using the immediate caller's class loader may allow the untrusted code to execute with the same privileges as the immediate caller.

...

Do not use the immediate caller's class loader as the third argument when instances must be returned to untrusted code.

Bibliography

...