Page History

...

With the exception of the loadLibrary() and load() methods, the tabulated methods do not perform any security manager checks. 

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.

...

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 accessibility. When the trusted code uses any of the tabulated APIs, it bypasses security manager checks (with the exception of loadLibrary() and load()).

With the exception of the loadLibrary() and load() methods, the tabulated methods fail to perform any security manager checks. The loadLibrary() and load() APIs are typically used from within a doPrivileged block; in that case, unprivileged callers can directly invoke them without requiring any special permissions. Consequently, the security manager checks are curtailed at the immediate caller. The security manager fails to examine the entire call stack and so fails to enhance security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may expose vulnerabilities.

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.

Noncompliant Code Example

In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block. This 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 the doPrivileged block stops security manager checks being applied to callers further up the execution chain.

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

Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability. However, after loading an additional unsafe library, an attacker can easily exploit the safe library if it contains other vulnerabilities. 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 method load() from public to private. Consequently, untrusted callers are prohibited from loading the awt library. 

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.

Noncompliant Code Example

In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block. This 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 the doPrivileged block stops any security manager checks being applied to callers further up the execution chain.

public void load(String libName) 

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

Noncompliant Code Example

A method that passes untrusted inputs to the Class.forName() method might permit an attacker to access classes with escalated privileges. The single argument Class.forName() method is another API method that uses its immediate caller's class loader to load a requested class. Untrusted code can misuse this API to indirectly manufacture classes that have the same privileges as those of the attacker's immediate caller.

public Class loadClass(String className) {
  // className may be the name of a privileged or even a malicious class
  return Class.forName(className);
}

Compliant Solution

This compliant solution hard-codes the class's name.

  }
  });
}

Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability. However, after loading an additional unsafe library, an attacker can easily exploit the safe library if it contains other vulnerabilities. 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 method load() 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; 
    }
  }

public Class loadClass() {
  return Class.forName("Foo");
}

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.

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

Compliant Solution

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

...