Java security has become an increasingly visible topic this year. Besides being front page news on both Microsoft's and Netscape's Web pages, technologies are becoming available as add-ons to increase the security of the Java environment. Researchers have already found a serious hole in the certificate-based security enhancement in JDK 1.1 and Microsoft and Netscape have both introduced new - and possibly incompatible - Java runtime environments that extend the security functionality provided by Sunsoft. Three goals are driving the flurry of activity to extend Java's security funtionality:
Java Security Accessory Kits
- The desire for increased reliability and higher assurance
- The search for increased functionality without an unacceptable increase in vulnerability
- The need for efficient and reliable security management for large numbers of users
Two commercial vendors and two universities are attempting to reduce the risks of executing Java applets by upgrading the runtime environment. These initiatives are the result of demand for increased reliability and assurance and a more effective management model. All of these efforts have converged on a firewall-like model of centralizing security management on a server at the organizational boundary. They differ in their approaches, but each is running some form of JVM functionality on the boundary server. Similar to a traditional proxy, which is essentially a gateway that performs access control and maybe some filtering, these technologies have the potential to support a much more sophisticated security policy. By performing security-relevant processing on a centrally-managed server, an organization can protect itself from users who might otherwise choose to run unapproved code. This month's article will introduce work that has been done by university students.
A Screening and Certification
System for Untrusted Java Applets
Elliot Berk, a graduating senior at Princeton University, has created a technology that augments the Java Virtual Machine to provide additional security by actually examining bytecode for hostile intent. His updated security manager class is available on-line for experimentation and his Senior Thesis, which describes the rationale behind his security architecture, is very interesting reading on Java security issues. (http://www.princeton.edu/~ejberk/AppletChecker)
The Secure Internet Programming (SIP) group at Princeton has taken part of Elliot's model and added a GUI interface to allow a site to centrally configure which Java applets can and cannot be downloaded and executed. Called the Java Filter, it is available for download at their site, http://www.cs.princeton.edu/sip/JavaFilter.
I recently had the chance to talk to Elliot about the technology he developed and how it works.
JDJ: Why did you choose this subject for your senior project?
EB: Going in, I had an interest in Internet security and an appreciation of how security is a prerequisite for confident, widespread use of the Web for commercial and business applications. With the Safe Internet Programming group at Princeton, I had access to the top researchers in the field.
JDJ: What kind of Java attacks have you seen?
EB: The common "attacks" on the Java security system that you see demonstrated on Web sites are not really what I would consider serious attacks or examples of malicious applets. These demonstration applets do not cause permanent damage to the client system and, at most, require the client machine to be rebooted.
I would think that very few people are actually hacking away at Java security and formulating really serious attacks, such as an applet that deletes local files of the browser user. That's fortunate.
The bad news is that if someone who really knew what they were doing tried to create such an applet, they might just be able to do so with surprising ease.
JDJ: What does your software do that browsers don't do?
EB: My software does a static examination of applet class files, searching for telltale signs of malicious behavior. Static detection of maliciousness is undecidable - like virus detection - but a static examination of class files can provide a significant amount of useful information.
The strategy of checking the security of an applet before execution is fundamentally different from the sandboxing technique of the Java security system. The latter waits until runtime, when it monitors applet behavior. The two techniques complement each other.
JDJ: Why don't you think that browsers do those checks?
EB: The overhead upon loading an applet class file could be significant. I do server caching to alleviate this problem.
JDJ: Do you think it's possible to implement the bytecode verifier in such a way that redundant security countermeasures won't be needed?
EB: Sure. That would just move my functionality into the only static part of the Java security system.
JDJ: Do you think that there will be a commercial market for Java security add-ons?
EB: That's possible, but it is natural for a large software firm like Netscape or Microsoft to simply assume that functionality in their browser.
JDJ: You've suggested peer reviews for security-relevant Java code.
EB: Collaborative efforts between major software firms have occurred recently to define Internet standards. An organization could be formed along these lines to mediate issues relevant to Java security.
JDJ: What do you envision for the future of Java? Will the Internet become completely dependent upon it?
EB: Java has become, and will continue to be, the Internet programming language of choice. Therefore, Java will have a prominent role in whatever commercial, business and entertainment applications emerge on the Web.
JDJ: While you were finishing your project, Sunsoft delivered JDK 1.1, with support for signed applets. Is this a positive development?
EB: Yes. It gives the software engineer greater freedom to design useful Web applications, and the browser user greater freedom to download and use them.
JDJ: You plan on doing more with Java after graduation?
EB: I suspect that anyone doing anything with software and the Internet will be dealing with Java.
Based on an ongoing secure operating environment project, the University of Washington's Kimera Architecture performs radical surgery on the JVM by centrally locating the bytecode verifier and the compiler on a server. They are augmenting these JVM functions with an audit manager - essential for tracking security incidents - and a code cache. Not only does this provide security advantages, but it could support highly-efficient clients that need only a minimal amount of runtime code. One of the first components of Kimera to be made available is their bytecode verifier. Developers can verify and disassemble their own Java classes on Kimera's server by entering a URL on a form at http://kimera.cs.washington.edu/verifier.html. Using this test suite, University of Washington students have found 24 flaws in Sun's Java Virtual Machine and 17 flaws in Microsoft's Internet Explorer.
Full project information is available at http://Kimera.cs.washington.
I recently spoke to Professor Brian Bershad of the University of Washington about Project Kimera (see Figure 1).
JDJ: What led you to choose this particular project?
BB: For the last four years, we've been developing an extensible operating system called Spin (http://www-spin.cs.
. The key aspect of Spin is that it relies on type safety to ensure integrity. Although the particular language we used is Modula3, many of the problems we ran into in developing Spin are the same as the Internet community is running into now with Java. We felt that Java offered us an opportunity to transfer some of our experiences to a more accessible platform.
JDJ: Is this an educational exercise for you, or do you envision commercial implementations of Kimera?
BB: It is the goal of any academic research project to have impact. If a commercial venture is the best way to achieve that impact, then we would consider it.
JDJ: Instead of modifying the runtime environment on the browser, you've chosen to put some of the runtime system on servers. Is this a new distributed server paradigm, client/server/server?
BB: The notion of a trusted computing base provided by secure servers that are in locked rooms away from users is an old one. There are several reasons to put the security smarts in a central place per organization: an organization can define its own security policies and server machines can be managed with limited physical and virtual access, which makes them much more secure. In contrast, client machines are generally quite vulnerable. By implementing security policies for a system such as Java on a vulnerable machine, an organization risks "giving away the store" if there is a breach. When flaws are found, it's much easier to upgrade a centralized site rather than having to get all the clients upgraded. It may not even be possible to find the clients. Centralized security services lend themselves well to audit trails, too.
JDJ: Can you give other examples of a distributed architecture that does application processing on more than one server?
BB:Most commerce Web sites you visit today have this architecture; there is a front-end Web server that speaks to a (more secure) back-end transaction server. Firewalls also have this structure.
JDJ: What do you think the risk is to a commercial site accessing Java applets today?
BB: I think there is substantial risk to people who run their browsers with Java enabled. There are dozens of known problems with current Java implementation, some known to be serious and some thought to be potentially serious. It doesn't take more than half a day with a disassembler and a rudimentary understanding of how JVM works internally to blow up a system based on one of the holes. Some of the blowups can be "harmless" in that they result only in a crash. Others can be much more serious, resulting, for example, in the theft of information from a browser or browser environment.
While it's comforting to believe that there are no documented cases of a hostile Java applet being encountered anywhere, I think it's unwise to interpret this as a sign that we're safe. It's just a matter of time. By analogy, for the first 15 years of the Internet it was widely known that there were holes all over the place. People said, "But nothing bad has happened yet so it can't be all that bad." And then along came Robert Tappan Morris with the Internet worm; this event was sufficient to convince people that there really was a problem and it needed to be solved.
It is in the vendors' best interests to sell their stuff as "highly secure" whether or not it is, since customers have no recourse if their system is breached. If vendors were really serious about security, then they would be providing guarantees about their systems' properties rather than trying to downplay each event as "mission impossible."
JDJ: Since you began development of your product, SunSoft has shipped JDK 1.1.1, which has support for signed applets. Is that complementary to your architecture?
BB: A signature provides an audit trail for customers to go after bad java applets. For the signature to mean anything though, it's necessary for the customer to be able to (a) figure out that they were compromised, and (b) figure out that the applet was responsible for the compromise.
By exploiting [vulnerabilities in] type safety, we've been able to develop applets which suck the memory out of the browser and send it back to an Internet server. Unless the applet says something, there is no way for the user to know that this is happening. A signature won't help here.
JDJ: What security advice would you give Java developers?
BB: Java is a nice programming language. It is not a secure system though, and should not, until additional technologies are developed to ensure security, be used as the basis for any programming where type safety provides the foundation for system integrity.
Next month's article will examine commercial Java security products from Finjan and Digitivity. The following article will highlight Microsoft and Netscape's Capability APIs and the specific support their JVM implementations will provide for signed applets.
About the Author
Jay Heiser is the JDJ Java Security Editor and the Director of Internet Products for HomeCom Internet Security Services. He has lectured on information security in the US and Europe at events such as InfoWarCon, The Internet Conference and FOSE. Jay also has animated several presentations on basic network security topics and made them available on the Web at www.homecom.com/services/hiss/LearnAbout.html. He can be reached at [email protected]