ENV01-J. Place all privileged code in a single package and seal the package

In Java SE 6, privileged code either uses the AccessController mechanism or needs to be signed by the owner (or provider) whom a user of the code can trust. An adversary is capable of linking privileged code with malicious code if some privileged code directly or indirectly uses code present within another package. This is called a mix and match attack. A mix and match attack is not possible if the code is signed because by default, the jarsigner tool signs the finished manifest that contains the names of the included classes along with their digests.

Privileges are lost as soon as untrusted code is executed. If trusted code calls some untrusted code that attempts to perform some action requiring permissions not granted by the security policy, the action is not allowed. However, privileged code may use a class that exists in an untrusted container and performs only unprivileged operations. If the attacker replaces this class with a malicious implementation, the trusted code will retrieve incorrect results.

According to the Java API [[JarSpec 2008]], JAR file specification

A package sealed within a JAR specifies that all classes defined in that package must originate from the same JAR. Otherwise, a SecurityException is thrown.

Sealing a JAR file automatically enforces the requirement of keeping privileged code together. In addition, it is important to adhere to guideline SEC01-J. Minimize the accessibility of classes and their members.

Noncompliant Code Example

This noncompliant code example uses a doPrivileged block and calls a method defined in a class that exists in a different, untrusted package.

package trusted;
import untrusted.RetValue;

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

      RetValue rt = new RetValue();

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

  }

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

package untrusted;

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

An attacker can provide an implementation of class RetValue so that the privileged code uses the wrong return value. If class MixMatch trusted only signed code, even then an attacker can cause this behavior by maliciously deploying a legibly signed class in the class path of the privileged code.

Compliant Solution

This compliant solution combines all privileged code into the same package and reduces the accessibility of the getValue() method to package-private. Sealing the package is necessary to prevent attackers from inserting any rogue classes.

package trusted;

public class MixMatch {
  // ...
}

package trusted;

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

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

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

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 2006]]
[[Ware 2008]]
[[McGraw 2000]] Rule 7: If You Must Sign Your Code, Put It All in One Archive File (sic)
[[MITRE 2009]] CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

      01. Runtime Environment (ENV)      ENV02-J. Create a secure sandbox using a Security Manager