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.

On June 23, we reported a serious security hole in Javasoft's JDK 1.1.2, 1.1.1 and Hotjava, by which textual information in a user's JVM, including passwords and browser history, can be compromised. The flaw, which does not exist in JDK 1.0.2, demonstrates two important facts:

• 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.
• A crash in a type safe system identifies a violation of type safety, and indicates a potential security hole. A flaw that results in a crash does not merely result in denial-of-service. It is quite often trivial to turn such a flaw into a security hole.

On April 23, we found a large number of flaws in Javasoft's JDKs 1.1.1 and 1.0.2, Microsoft's Internet Explorer and Netscape Navigator Gold. There were 24 flaws in the two JDKs and Netscape Navigator Gold, and 17 flaws in Microsoft Internet Explorer. Ten of the flaws were in common between IE and Netscape, and were only discovered by comparing against our own verifier. One major security hole, which prompted Microsoft to do a full security release, was among the flaws in common. Javasoft also released a patch for a suspected security flaw in JDK 1.1.1.

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. We do a test run after every change to our verifier to find and fix flaws in our own verifier. This process has so far yielded lengthy lists of flaws in commercial verifiers as a by-product, which we have made public as a service to the Java community. 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.