BUY IT!
Securing Java

Previous Page
Previous Page
Attack Applets: Exploiting Holes in the Security Model
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13 / 14 / 15 / 16 / 17 / 18 / 19 / 20

Section 17 -- The Vacuum Bug

Next Page
Next Page

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.


Why the Flaw Was Exploited

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.

Previous Page
Previous Page

The Web
securingjava.com

Next Page
Next Page


Menu Map -- Text links below

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.