If an end-user loads code signed by "Alice", and Alice is included on the list of trusted signatures, Alice's code is allowed to step outside the Java sandbox model (which limits applets to the same minimal privileges).

In the following attack scenario, Alice's code can appear to have been signed by another signature on the list of signatures known to the system, e.g. "Bob." That is, Alice's code could tell the system "treat me as if I've been signed by Bob."

This attack works even if the system does not know the identity of "Alice."

The attack works in two stages. First, the attack applet acquires the ability to change the system's idea of who signed it. Then it gets a list of all signers known to the local system, and "tries on" the these identities one by one until it finds one that is trusted. Having done this, the applet is free of any security restrictions.

1. How the attacker changes its identity

The attacker calls the getSigners() method of the java.lang.Class class. This returns an array of signers who have signed the class. The JDK 1.1.1 code mistakenly returns a reference to its own internal array. Since Java arrays can be modified, the attack applet can then replace any element of the array, thereby changing Java's idea of who signed it.

2. How the attacker finds a trusted identity to assume

The method getSystemScope() of the class java.security.IdentityScope returns an IdentityScope object (call it s). Calling s.identities() gets an enumeration of all identities known to the local system.

The attack applet can try each of these identities one at a time. After changing to a new identity, the applet tries a privileged operation, i.e. writing a file. If this causes a security exception, the current identity is not trusted, so the applet goes on to the next identity. If the operation succeeds, then the applet knows it has acquired trusted status, and it is free to do whatever it wants.