Javasoft/Sun Flaw #25: The Vacuum Bug
Security Flaw in JDK 1.1
June 23, 1997

We have found a security hole in Javasoft's HotJava browser and JDK 1.1.2, the latest Java implementation from Javasoft. The security hole enables a malicious applet to read textual information from the HotJava browser and the Java virtual machine, such as a user's password, browser history, cache contents, private security keys and portions of previously read files. We developed an example exploit (click here for a description) that retrieves this information from a user's browser and sends it over the network to a scavenger site. Once a user clicks on a page containing the rogue applet, there is no way to stop the information leak from the user's machine except by killing the browser.

The exploit is based on a typesafety flaw in the Java verifier. The verifier is the system component that inspects untrusted, foreign, or potentially malicious code and performs dataflow analysis on the code to determine if it adheres to the JVM safety constraints. The verifier checks untrusted code for typesafety, the key safety property on which Java's security rests. Any failure of the verifier to reject code that does not conform to the Java bytecode specification is a flaw as it can result in a circumvention of typesafety, leading to security and/or privacy violations.

We found this flaw using our testing methodology. We compared Javasoft's latest commercial JVM implementation against our own strong verifier on a test suite of automatically generated classes. Whenever Javasoft's JDK 1.1.2 made a security/verification decision that differed from ours, we noted a potential flaw.

This flaw can manifest itself as a browser crash, which occurs whenever the browser attempts to access inaccessible memory. We used MSDEV, a standard PC debugger, to identify the instruction in the browser at which the bad access occurred, and identified a path by which it was possible to:

a. direct the browser's instruction to a legitimate range of memory
b. force the browser to read arbitrary ranges of its memory and direct the text strings found in those ranges back to the server from which the class file was loaded.

This bug underscores the importance of correctly specifying, implementing and assuring the Java verifier, since the Java security architecture relies on type safety. It further demonstrates that there is no such thing as a "less serious" typesafety flaw in a system where overall system integrity is predicated on typesafety.

To summarize:

Click here to go to the main project page which describes our proposed security architecture for Java.

Click here for the previous set of flaws we found in commercial Java implementations.

If you would like to receive email notification in the future about other flaws discovered by our group, please send us your email address, name and a very brief description of how you intend to use the information.

Emin Gün Sirer & Brian Bershad

Project Kimera
Department of Computer Science and Engineering
© 1997, University of Washington