[Image]                Security Flaws in Java Implementations

----------------------------------------------------------------------------

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.

This list of flaws is by no means exhaustive. Our testing methodology,
combined with our secure verifier, allows us to continually and
automatically test for flaws in commercial Java implementations. Our
disassembler helps us easily examine the flaws uncovered by automatic
testing. There are numerous categories of flaws that we have not yet
examined. We will be investigating those categories in detail as we develop
our research infrastructure.

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.
                       [Image] Security hole
                       [Image] Possible security hole
                       [Image] Weakness
                       [Image] 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.

----------------------------------------------------------------------------

               Emin Gün Sirer & Sean McDirmid & Brian Bershad

                               Project Kimera

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