We have developed an alternative security architecture for Java and are in the process of implementing and evaluating it. In the course of this work and in conjunction with our previous experience with safe extensible systems, we implemented a secure Java verifier. In order to test our verifier implementation, we developed an automatic testing methodology that covers a large number of security attacks. Application of our test suite against commercial Java implementations exposed a number of security holes, weaknesses, and ambiguities in commercial Java verifiers.

Overall, we have found twenty four flaws in Sun's Java implementations and seventeen flaws in Microsoft's Internet Explorer. The Sun Java development kits form the basis of the Java implementation in Netscape Navigator and Communicator. Both Sun and Microsoft have released security patches for some of the flaws that we identified.

Types of Flaws

It is important to note that not all flaws have the same consequences. Some Java verifier flaws are security holes, where exploitation of the flaw leads to either access to protected information, such as credit card numbers, or access to protected services, such as the ability to read or write to the local disk and to form and send data across network connections. We consider security holes a serious risk, especially because the rise of electronic commerce has placed financial resources at the disposal of computers connected to the Internet. We have demonstrated that at least one of the flaws we have found constitutes a security hole. There are some flaws that, while we have not yet demonstrated that they are security holes by exploiting them, seem dangerously close as they involve breakdowns in the typesafety guarantees of Java. We demarcate such flaws as possible security holes and have notified respective vendors of their existence.

Most flaws tend to be weaknesses, where the Java virtual machine (JVM) implementation is unable to detect applets that do not conform to the Java virtual machine specification. A weakness does not pose an immediate security risk to the integrity of the JVM, but may well pose a security risk to the integrity of applets. For example, a JVM may fail to check that a byte that is required to hold a certain value actually holds that value. This may be benign provided that the JVM does not make any assumptions about the byte's value. There is a weakness, however, since the assumptions may exist but be hard to trigger, or they can be added later on in the lifetime of the project. For another example, a JVM that allows a nonconforming applet to execute may be manipulated by another applet to force the first applet to perform operations that the applet writer did not intend to perform. We believe that JVM vendors need to identify and eliminate all instances where the JVM executes non-conforming applets.

Finally, there are some ambiguities in the Java Virtual Machine Specification that could result in an applet that is written with one set of assumptions to perform unintended actions on systems with differing assumptions. For Java to become ubiquitous and Java code to become trustable, we believe that JVM implementations should enforce their interpretation of the JVM specification, and that the specification must be strengthened to remove all ambiguities.

Descriptions

Here are the technical descriptions of the problems we have found in commercial Java Virtual Machine implementations. They have been edited to give a flavor of the types of flaws we found without disclosing the actual flaws until the installed user base has had a chance to incorporate the new security fixes. We have classified every flaw based on their possible consequences with the following icons.

	Security hole
	Possible security hole
	Weakness
	Ambiguity

• Flaws in Sun's JDK 1.1.1 and 1.0.2, found as of April 23, 1997.
• Flaws in Microsoft's Internet Explorer, found as of April 23, 1997.