SEC02-J. Do not expose standard APIs that may bypass Security Manager checks to untrusted code

When one of the methods from the highlighted table is invoked on a Class, ClassLoader or Thread object, a comparison is run between the method's immediate caller's class loader and that of the object. As an example of what constitutes the immediate caller and the object, consider the method java.lang.Class.newInstance(). Here, the immediate caller is the class that contains this method call whereas the object is called the Class object, the one on which newInstance() is invoked (classObjectName.newInstance()).

According to the Java Language Specification [[JLS 05]] section 4.3.2 "The Class Object": "The method getClass returns the Class object that represents the class of the object". The first ten methods shown below can be used on a Class object.

Security manager checks may get bypassed depending on the immediate caller's class loader. Consider for instance, the ClassLoader.getSystemClassLoader() and ClassLoader.getParent() methods that operate on a ClassLoader object. In the presence of a security manager, these methods succeed only if the immediate caller's class loader is the delegation ancestor of the ClassLoader object's class loader or if the immediate caller's class loader is the same as the the ClassLoader object's class loader or if the code in the current execution context has the RunTimePermission, namely "getClassLoader".

Noncompliant Code Example

The newInstance() method is being invoked on the dateClass Class object. The issue is that the untrustedCode method can trigger the instantiation of a new class even though it should not have the permission to do so. This behavior is not caught by the security manager.

public class ExceptionExample {
   public static void untrustedCode() {
     Date now = new Date();
     Class<?> dateClass = now.getClass();
     createInstance(dateClass);
    }

    public static void createInstance(Class<?> dateClass) {
      try { // Create another Date object using the Date Class
        Object o = dateClass.newInstance();
        
        if (o instanceof Date) {
          Date d = (Date)o;
          System.out.println("The time is: " + d.toString());
        }
      }
      catch (InstantiationException ie) { System.out.println(ie.toString()); }
      catch (IllegalAccessException iae) { System.out.println(iae.toString()); }    	
    }
}

A related issue is described in SEC03-J. Do not use APIs that perform access checks against the immediate caller.

Compliant Solution

Do not accept Class, ClassLoader or Thread instances from untrusted code. If inevitable, safely acquire these instances by ensuring they come from trusted sources. Additionally, make sure to discard tainted inputs from untrusted code. Likewise, objects returned by the affected methods should not be propagated back to the untrusted code.

Note that the Class.newInstance() method requires the class to contain a no-argument constructor. If this requirement is not satisfied, a runtime exception results, which indirectly prevents a security breach.

Risk Assessment

Bypassing Securitymanager checks may seriously compromise the security of a Java application.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[Gong 03]] Section 4.3.2, Class Loader Delegation Hierarchy
[[SCG 07]] Guideline 6-2 Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader

SEC01-J. Provide sensitive mutable classes with unmodifiable wrappers      02. Platform Security (SEC)      SEC03-J. Do not use APIs that perform access checks against the immediate caller