Page History

Most methods perform no security manager checks because they do not provide access to sensitive parts of the system, such as the filesystemfile system. Most methods that do provide security manager checks check verify that every class and method in the call stack is authorized before they proceed.  This it proceeds. This security model allows restricted programs, such as Java applets, to have full access to the core Java library. This security model It also prevents a sensitive method from acting on behalf of a malicious method that hides behind a trusted method in the call stack.

However, certain methods use a reduced security check , that checks only checks that the calling method has access , rather then than checking every method in the call stack. Code that invokes these methods must guarentee guarantee that they are not being invoked on behalf of untrusted code. These methods are :listed in the following table.

Because the java.lang.reflect.Field.setAccessible/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 discussed in this guideline. Nevertheless, these methods should be used only with extreme caution. The remaining set* and get* field reflection methods perform only the language access checks and consequently are vulnerable. 

Class loaders allow a Java application to be dynamically extended at runtime by loading 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 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.

Several methods, that which are charged with loading classes, delegate their work to the class loader of the class of the method that called them. The security checks associated with loading classes is are often performed by class loaders. Consequently, any method that invokes one of these class-loading methods must guarentee guarantee that these methods are not acting on behalf of untrusted code. These methods are :listed in the following table.

...

In practice, the trusted code's class loader frequently allows these methods to be invoked, whereas 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 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 fundamental to many Java implementations and frameworks. So the The best advice is to avoid exposing the methods listed above in the table 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, 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 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 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 itsdeclared accessibility. When the trusted code uses any of the tabulated APIs, it bypasses security manager checks (with the exception of loadLibrary() and load()). 

This guideline is an instance of 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.

...

In this noncompliant code example, a call to System.loadLibrary() is embedded in a doPrivileged block.  This It 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 from the library, if those methods are accessible. This is possible because , because the doPrivileged block stops any security manager checks being applied to callers further up the execution chain.

...

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

...

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 an a SQL connection can bypass these restrictions by using the acquired instance directly.

...

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 users from supplying their own URL to the database connection; , thereby limiting their ability to load untrusted drivers.

private String url = // hardwiredHardwired value

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

...

Java 1.7.0u10 was 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 a Class object. This method delegated its work to the loadClass() method, whose source code is shown here:

/**
 * Load a class with the specified loader, or with this object
 * class loader if the specified loader is null.
 **/
static Class<?> loadClass(String className, ClassLoader loader)
    throws ReflectionException {

    Class<?> theClass;
    if (className == null) {
        throw new RuntimeOperationsException(new
            IllegalArgumentException("The class name cannot be null"),
                          "Exception occurred during object instantiation");
    }
    try {
        if (loader == null)
            loader = MBeanInstantiator.class.getClassLoader();
        if (loader != null) {
            theClass = Class.forName(className, false, loader);
        } else {
            theClass = Class.forName(className);
        }
    } catch (ClassNotFoundException e) {
        throw new ReflectionException(e,
        "The MBean class could not be loaded");
    }
    return theClass;
}

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

...

Oracle mitigated this vulnerability in Java 1.7.0p11 by adding an access check to the 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)
// ...

Noncompliant Code Example (CERT

...

Vulnerability 636312)

CERT Vulnerability 636312 describes a vulnerability in Java that was successfully 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.)

The exploit runs as an applet. 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).

...

public static Class<?> findClass(String name) throws ClassNotFoundException {
  try {
    ClassLoader loader = Thread.currentThread().getContextClassLoader();
    if (loader == null) {
      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);
}

While Although this method is called in the context of an applet, it uses Class.forName() to obtain the requested class. And 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 trusting class loader is used , instead of the more paranoid applet class loader.

...

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

...

Related Guidelines

Bibliography

Oracle Security Alert for CVE-2013-0422
Manion, Art, Anatomy of Java Exploits, CERT/CC Blog, January 15, 2013 2:00 PM

...

...

 , August 28, 2012[Chan 1999] java.lang.reflect AccessibleObject

...

Image Modified Image Modified