JavaSoft reviewed Princeton's example of the attack and created a fix over the weekend, which we began testing on Monday, April 28. We released a fix to our licensees -- the community who is most involved in JDK 1.1.1 at this point -- on April 29.

JavaSoft will incorporate the bug fix in the next shipping version of the JDK, JDK 1.1.2, in mid-May.

JavaSoft publishes the complete source code for the JDK -- this is instrumental in uncovering bugs. We invite scrutiny from the internet community, and we publish the full source code so that the internet community will be able to analyze our security implementations, give us feedback on the architecture and implementation, and build up trust in the architecture and implementation. This openness has the effect of attracting a lot of attention to Java security, but we believe that the best way to evolve the Java security model is in this spirit of openness.

What's the bug?

In the attack designed by the Princeton team, digitally signed code can be manipulated to impersonate another digital signature from the list of signers that are recorded in the Java runtime.

What's the exposure?

We believe this implementation bug represents minimal exposure to users for the following reasons.

Neither Microsoft Internet Explorer nor Netscape Navigator include support for this particular API at this time. Licensees haven't yet integrated this functionality into any shipping product.

HotJava does include support for signed applets and Class.getSigners(), but thanks to its easy-to-use security adminstration GUI, end-users can easily turn off access to signed applets, circumventing the bug entirely.

What's the fix?

The fix is in the shared native code for the Class class, in the file src/share/java/lang/class.c. It is a straightforward bug and a straightforward fix. The fix was sent to all Java licensees on April 29. The fix will be included in JDK 1.1.2, which is shipping in mid-May.

Can you give more details on the bug?

For example, 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.

In the Princeton 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."

Unsigned code cannot exploit this attack. That is, unsigned code cannot impersonate signed code.

In technical terms, the bug is in Class.getSigners(). getSigners() returns the list of signatures associated with the code that invokes getSigners(). There is a bug in getSigners() that can be exploited so that the system thinks that code signed by one identity is signed by a different identity.