Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Consider, for example, untrusted code that is attempting to load a privileged class. Its class loader is permitted to delegate the class loading to the trusted class's class loader. This can result in privilege escalation, because the untrusted code's class loader may lack permission to load the requested privileged class. Further, if the trusted code accepts tainted inputs, the trusted code's class loader could load additional privileged — or even malicious — classes on behalf of the untrusted code.

Noncompliant Code Example

In this noncompliant code example, the untrustedCode() method of class Untrusted invokes the loadLib() method of class NativeCode. This is insecure because the library is loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load the intended library even though it lacks sufficient permissions. After loading the library, untrusted code can call native methods on it if the methods are accessible.

Code Block
bgColor#FFcccc
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.

...

bgColor#ccccff

...

This guideline is an instance of SEC04-J. Protect sensitive operations with security manager checks. 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. An unprivileged caller can maliciously invoke this piece of code using the same technique as above because the doPrivileged block stops security manager checks being applied to callers further up the execution chain.

...

Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability, but 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 lucrative targets.

Compliant Solution

This 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.

Code Block
bgColor#ccccff
private void load() {
  AccessController.doPrivileged(new PrivilegedAction() {
    public Object run() { 
      System.loadLibrary("awt");
      return null; 
    }
  });
}

Noncompliant Code Example

Accepting tainted inputs from untrusted code can permit an attacker to load 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.

Code Block
bgColor#FFcccc
// 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 hard-codes the class's name.

Code Block
bgColor#ccccff
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. Untrusted code that lacks the permissions required to create a SQL connection can bypass these restrictions by using the acquired instance directly.

Code Block
bgColor#FFcccc
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. It is preferable to reduce the accessibility of methods that perform sensitive operations and define wrapper methods that are accessible from untrusted code.

...