Page History

In Java SE 6, privileged code either uses the AccessController mechanism or must be signed by an owner (or provider) who is trusted by the user. Attackers could link privileged code with malicious code if the privileged code directly or indirectly invokes code from another package. In fact, a trusted jar file files often contains contain code that is not privilegedlacks direct privileges, but that depends on privileged code, this ; such code is known as security-sensitive code. If an attacker can link security-sensitive code with malicious code, they can indirectly cause incorrect behavior with sensitive data. This is called a mix and match attack.

Execution of untrusted code causes loss of privileges. If When trusted code calls some untrusted code that attempts to perform some action requiring permissions not granted withheld by the security policy, the action is not allowedforbidden. However, privileged code may use a class that exists in an untrusted container , performing and performs only unprivileged operations. If the attacker replaces were to replace this class with a malicious implementation, the trusted code will would retrieve incorrect results.

...

An attacker can provide an implementation of class RetValue so that the privileged code uses the wrong an incorrect return value. Even if though class MixMatch consists only of trusted, signed code, an attacker can still cause this behavior by maliciously deploying a legally signed jar file containing the untrusted RetValue class.

...

This noncompliant code example improves upon the previous one by moving usage the use of the RetValue class outside the doPrivileged() block.

package trusted;
import untrusted.RetValue;

public class MixMatch {
  private void privilegedMethod() throws IOException {
    try {
      final FileInputStream fis = AccessController.doPrivileged(
        new PrivilegedExceptionAction<FileInputStream>() {
          public FileInputStream run() throws FileNotFoundException {
            return new FileInputStream("file.txt");
          }
        }
      );
      try {
        RetValue rt = new RetValue();

        if (rt.getValue() == 1) {
          // do something with sensitive file
        }
      } finally {
        fis.close();
      }
    } catch (PrivilegedActionException e) {
      // forward to handler and log
    }
  }

  public static void main(String[] args) throws IOException {
    MixMatch mm = new MixMatch();
    mm.privilegedMethod();
  }
}


// In another jar file:
package untrusted;

class RetValue {
  public int getValue() {
    return 1;
  }
}

While Although the RetValue class is not used within only outside the doPrivileged() block, the behavior of RetValue.getValue() certainly affects the behavior of security-sensitive code; that is, the code that operates on the file opened within the doPrivileged() block. So Consequently, an attacker can still exploit the security-sensitive code with a malicious implementation of RetValue.

...

This compliant solution combines all security-sensitive code into the same package an dthe and the same jar file. It also reduces the accessibility of the getValue() method to package-private. Sealing the package is necessary to prevent attackers from inserting any rogue classes.

...

To seal a package, use the sealed attribute in the jar file's manifest file header. This is , as shown below.

Name: trusted/ // package name
Sealed: true  // sealed attribute

...

ENV01-EX0: Independent groups of privileged code and associated security-sensitive code (a "group" hereafter) may be placed in separate sealed packages and even separate jar files, as long as certain enabling conditions are met. The enabling condition is that the These conditions are:

• The code in any one of these

...

• independent groups lacks any dynamic or static dependency on any of the code in any of the other

...

• groups. This means that code from one such

...

• cannot cannot invoke code from any of the others, whether directly or transitively.
• All code from any single group is contained within one or more sealed packages.
• All code from any single group is contained within a single signed jar file.

Risk Assessment

Failure to place all privileged code together in one package and seal the package can lead to mix and match attacks.

...