Page History

In Java SE 6, privileged code either uses the AccessController mechanism or needs to must be signed by the an owner (or provider) whom a user of the code can trust. An adversary is capable of linking who is trusted by the user. Adversaries could link privileged code with malicious code if some the privileged code directly or indirectly uses invokes code present within from 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 Execution of untrusted code is executedcauses loss of privileges. 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.

...

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

...

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

Exception

ENV01-EX1: Independent groups of privileged code may be placed in separate sealed packages. The enabling condition is that the code in any one of these packages lacks any dynamic or static dependency on any of the other packages. This means that code from one such package must not invoke code from any of the others, whether directly or transitively.

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

TODODetecting code that should be considered privileged or sensitive requires programmer assistance. Given identified privileged code as a starting point, automated tools could compute the closure of all code that may be invoked from that point. Such a tool could plausibly determine whether all code in that closure exists within a single package. A further check of whether the package is sealed appears feasible.

Related Vulnerabilities

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

...

\[[API 2006|AA. Bibliography#API 06]\]
\[[Ware 2008|AA. Bibliography#Ware 08]\]
\[[McGraw 2000|AA. Bibliography#Ware 00]\] Rule 7: If You Must Sign Your Code, Put It All in One Archive File (sic)
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data|http://cwe.mitre.org/data/definitions/349.html]
\[[Ware 2008|AA. Bibliography#Ware 08]\]

...

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