Page History

In Java SE 6 and Java SE 7, privileged code must either use the AccessController mechanism or be signed by an owner (or provider) whom the user trusts. Attackers could link privileged code with malicious code if the privileged code directly or indirectly invokes code from another package. Trusted JAR files often contain code that lacks direct privileges requires no elevated privileges itself, but that depends on privileged code; such code is known as security-sensitive code. If an attacker can link security-sensitive code with malicious code, he or she can indirectly cause incorrect behavior with sensitive data. This is called a mix-and-match attack.

Execution of untrusted code causes loss of privileges. When trusted code calls untrusted code that attempts to perform some action requiring permissions withheld by the security policy, the that 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 were to replace the class in the trusted container with a malicious implementation, the trusted code might retrieve incorrect results and cause the privileged code to misbehave at the attack's discretion.

...

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

This example comes close to violating almost violates rule SEC01-J. Do not allow tainted variables in privileged blocks but does not do so. It instead allows potentially tainted code in its doPrivileged() block, which is a similar issue.

...

...