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.
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.
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.