| |
| History |
|
| People |
|
| Partners |
|
| Research |
|
| Publications |
|
| FAQ |
|
| Links |
|
Last modified: Wed Apr 30 23:15:55 EDT 1997
BackgroundSun'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.
The attackWe 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 worksWarning: this section gets technical in spotsThe 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 identityThe 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 assumeThe 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. |
|
Department of Computer Science Contact: sip@cs.princeton.edu |