Last modified: Wed Apr 30 23:15:55 EDT 1997
Sun's JavaSoft has recently released
version 1.1 of their Java language. Among many new features of the
system, JDK 1.1 includes support for digital signatures, allowing some
applets to have additional privileges beyond the traditional
sandbox model (which limits all applets to the same minimal
privileges). Sun also released HotJava 1.0, a Web
browser using many of these new features.
We recently discovered a bug in how these signatures are managed
internally. As a result, an unprivileged, but signed, applet can
act as if it were signed by anybody. In particular, our applet
will scan through your list of trusted signatures and
impersonate one of them.
If you use HotJava 1.0 and you trust any signature, we can
compromise your system.
Note: this security hole does not effect Microsoft's
Internet Explorer or Netscape's Navigator or Communicator.
How the attack works
Warning: this section gets technical in spots
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.
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.
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.