Sun Flaw #25: The Vacuum Bug

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:

This typesafety flaw has serious security and privacy consequences. It enables information scavenger applets to send private information within the browser's address space including names, passwords, browser history and browser cache, to remote scavenger sites. The user is unlikely to notice this is occuring, and the information leak is stopped only when the browser is manually terminated.
This flaw manifested itself as a crash. We have encountered other crashes that result from the verifier incorrectly accepting illegal Java class files as valid. Such "crash" flaws indicate that other similar vulnerabilities may exist.
This flaw does not exist in JDK 1.0.2. It appears to have been introduced as part of the development process leading to JDK 1.1.2. We do not believe that the JDK verifier was intentionally weakened during this process; it is more likely that the bug was introduced as a side effect of other actions. While it is often said that systems can get safer over time, only carefully controlled trusted computing bases and comprehensive testing methodologies can ensure this.
Access to JVM source is not necessary to understand or exploit this flaw. Although the flaw requires one to hand modify a Java class file at the bytecode level, most undergraduates studying computer science have the necessary programming skills to do so. The only tools required are a Java disassembler, an x86 disassembler, and a rudimentary understanding of java and x86 assembly language.
Microsoft's Internet Explorer and Netscape Navigator/Communicator do not appear to be affected by this flaw. The flaw was found in JDK 1.1.2 and JDK 1.1.1 on PC and Sun platforms.
We suggest that users who use JDK 1.1.2 and JDK 1.1 based products such as Hotjava in safety, security or privacy-critical applications obtain and apply all relevant security patches from Javasoft. Alternatively or in addition, users may want to send untrusted Java code through a strong verifier before admitting it into their systems.

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

Project Kimera

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

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