(THIS CODING RULE OR GUIDELINE IS UNDER CONSTRUCTION)

Many static methods in standard java APIs vary their behavior according to the immediate caller's class. Such methods are considered to be caller-sensitive. For example, the java.lang.System.loadLibrary(library) method uses the immediate caller's class loader to find and dynamically load the specified library containing native method definitions. Because native code bypasses all of the security checks enforced by the Java Runtime Environment and other built-in protections provided by the Java virtual machine, only trusted code should be allowed to load native libraries. None of the loadLibrary methods in the standard APIs should be invoked on behalf of untrusted code, since untrusted code may not have the necessary permissions to load the same libraries using its own class loader instance.

Noncompliant Code Example

import java.security.*;

public class Trusted {

   public static void loadLibrary(final String library){
      AccessController.doPrivileged(new PrivilegedAction<Void>() {
         public Void run() {
             System.loadLibrary(library);
             return null;
         }
      });
   }
}

////////////////////////////////////////////////////////////////////////////////////

public class Untrusted {
   static{
      System.setProperty("java.security.policy", "java.policy");
      SecurityManager sm = new SecurityManager();
      System.setSecurityManager(sm);
      System.out.println("Allowed!");
   }

   private native void sayHello();

   public static void main(String[] args) {
      String library = new String("HelloImpl");
      Trusted.loadLibrary(library);
      new Untrusted.sayHello();  // invoke the native method
   }
}

Compliant Solution

Exceptions

Risk Assessment

Failure to define wrappers around native methods can allow unprivileged callers to invoke them and exploit inherent vulnerabilities such as buffer overflows in native libraries.

Automated Detection

Related Guidelines

Bibliography