In June of 1997, the Kimera Project team uncovered another security hole in JDK 1.1.2 and the HotJava browser. Like the previous 24 flaws discovered, the new security hole had at its core a type-safety flaw in the Verifier. Prompted into further action by Sun's response to the first announcement, the Kimera Project team decided to create a complete exploit based on the new flaw. That was one way to emphasize that type-safety problems should always be taken seriously!
The flaw itself existed only in JDK 1.1.1 and JDK 1.1.2 and was never present in either of the major browsers. By itself, the flaw manifests itself as a VM/browser crash (the browser being HotJava). That is, an applet that passes the Verifier with flying colors would end up crashing the VM when it actually ran. The crash is caused when the applet directs the browser to access inaccessible memory.
Using a PC debugger (MSDEV), Kimera team members were able to determine which instruction was causing the browser to crash. With this information in hand, it was possible to cause the browser to jump to a legitimate address and start reading arbitrary memory ranges. In a strings-like move, the malicious code directed an ASCII text version of the targeted memory range back to a collection server.
The attack applet created by Kimera exploited the type-safety problem to carry out this attack. The most pernicious aspect of the attack was the applet's ability to determine sensitive information about the user from the browser's memory space, including configuration settings, private crypto keys, name, email address, browser history, cache contents, etc.
Other than its ability to steal sensitive data, the main purpose of the attack applet was to demonstrate that what Sun had called "less serious" type-safety problems could be easily turned into full-fledged attacks. Java has at its heart a language-based security model. Such models depend completely on the type system to provide security guarantees.
Copyright ©1999 Gary McGraw and Edward Felten.