Page History

In the presence of a security manager and a restrictive system-wide security policy, untrusted code is prohibited from performing privileged operations. For example, instantiation of sensitive classes such as java.lang.ClassLoader is prohibited in the context of a web browser. At the same time, it is critical to ensure that untrusted code does not indirectly use the privileges of trusted code to perform privileged operations. Most APIs install security manager checks to prevent this, however, some do not. These APIs are tabulated below, with the exception of the loadLibrary APIs. The loadLibrary APIs throw a security exception if the caller does not have permissions to dynamically link the library code. However, it is listed as unsafe because it uses the immediate caller's class loader to find and load the library. Moreover, because the loadLibrary API is typically used from within a doPrivileged block defined in trusted code, untrusted callers can directly invoke it.

...

class NativeCode {
  public native void loadLib();

  static {
    try {
      System.loadLibrary("/com/foo/MyLib.so");
    }catch(UnsatisfiedLinkError e) { e.getMessage(); }
  }    
}

class Untrusted {
  public static void untrustedCode() {
    new NativeCode().loadLib();
  }
}

Compliant Solution

Ensure that untrusted code cannot invoke the affected APIs directly or indirectly (that is, via a call to an invoking method). In this case, the loadLib() method must be declared private so that it is only available to a more restrictive wrapper method within the class. The restrictive wrapper method can ensure that the caller can safely invoke the library.

private final native void loadLib();

Noncompliant Code Example

Sometimes, a call to System.loadLibrary() is embedded in a doPrivileged block, as shown below. An unprivileged caller can maliciously invoke this piece of code using the same technique because the doPrivileged block allows security manager checks to be forgone for other callers on the execution chain.

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

Non-native library code can also be susceptible to related security flaws. Loading a non-native safe library, by itself may not expose a vulnerability but after loading an unsafe library, an attacker can easily exploit it if it contains other vulnerabilities. Moreover, non-native libraries often use doPrivileged blocks, making them lucrative targets.

Compliant Solution

Ensure that untrusted code cannot invoke the affected APIs directly or indirectly (that is, via a call to an invoking method). In this case, the loadLib() method must be declared private so that it is only available to a more restrictive method within the class. The restrictive method can ensure that the caller has sufficient permissions to load the libraryThis 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 final native void loadLib(); void load() {
  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() { 
      System.loadLibrary("awt");
      return null; 
    }
  });
}

Noncompliant Code Example

Accepting tainted inputs from untrusted code can further exacerbate the issue. The single argument Class.forname() method is another example of an API that uses its immediate caller's class loader to load a desired class. Untrusted code can indirectly misuse this API to manufacture classes with the same privileges as those of the immediate caller.

// className may be the name of a privileged or even a malicious class
Class c = Class.forName(className);

Compliant Solution

Limit the visibility of the method that uses this API. Do not operate on tainted inputs. This compliant solution hardcodes the class's name.

Class c = Class.forName("Foo"); // Explicitly hardcode

Noncompliant Code Example

This noncompliant code example returns an instance of java.sql.Connection from trusted to untrusted code. The untrusted code that does not have the permissions to create an SQL connection can bypass this restriction by directly using the acquired instance.

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

Compliant Solution

Ensure that instances of objects created using the unsafe methods are not returned to untrusted code. Furthermore, it is preferable to reduce the accessibility of methods that perform sensitive operations and define wrapper methods that are accessible from untrusted code.

...