Approved by:
___________________________________________________________
Dr. Edward Chow
__________________________________________________________
Dr. Robert W. Sebesta
________________________________________________________
Dr. Jugal Kalita
The Java language [1] is a simple, object-oriented, portable, robust language developed at Sun Microsystems. Java code runs on a virtual machine, thus it can be ported to almost every computer system available today. This makes it suitable to use in a heterogeneous network environment such as the Internet. The Java language allows Java compatible Web-browsers to download code fragments dynamically and then to execute those fragments locally.
Java has a great potential, but the actual use of Java technology in real business applications is pretty limited today. There are two main reasons for this; security concerns and restrictions on the Java run-time environment.
Sun's stated goal is to prohibit applets from "inspecting or changing files on a client file system" and "using network connections to circumvent file protections or people's expectations of privacy" [2].
Sun has made a good job in trying to reach their stated goal. A straightforward approach is simply not enough to challenge the security of the Java run-time system. Nevertheless, several security bugs have already been discovered, and it is possible to expose others by exploiting the language in unexpected ways.
Several bugs have been discovered by Drew Dean, Ed Felten, and Dan Wallach of Princeton University [3]. One bug, called the Array Name Bug was published in August 1996. Due to incorrect handling of type definitions it was possible to completely circumvent Java's security mechanisms.
Another example of a security flaw found by the team at Princeton allowed an attacker to attack victims normally protected by a firewall. This attack method exploited the Java runtime systems trust in remote DNS servers. An applet is normally only allowed to connect to the host it originated from. By providing bogus DNS information from a remote DNS service an malicious applet was allowed to connect to arbitrary hosts inside the victims firewall.
David Hopwood an U.K researcher at Oxford, has also discovered serious security breaches in the Java run-time environment [4].
Other types of attacks does not exploit security breaches in Java. Instead Java is used as a tool to violate Internet users privacy or integrity. Information useful to a hacker such as Java version, operating system name and architecture could be passed anonymously to a server by an applet hidden in a HTML document.
A more sophisticated method presented by Edward E. Felten et. Al [5] describes how an attacker could present a forged version of the whole WWW to a victim. By doing that a victim could be lured into presenting PIN and credit card numbers to the attacker. Java is only a component in this attack scenario and can be replaced by other similar technologies.
The so called, electronic underground, is of course also exploring the capabilities of Java. Collections of malicous applets can be found at "Hostile Applets Home Page" [6] and DigiCrime's homepage [7].
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host. This is of course also a disadvantage. Because as effective as it prevents hostile applets from accessing resources it prevents other applets from doing their work.
Corel Corporation has developed a suite of desktop programs called Corel Office for Java [8]. These programs are unable to print and store documents on the local system. All I/O must be handled at a shared server. There are two ways to get around these restrictions. Either run the Corel Office for Java applets as stand alone Java applications or to use a Web-browser that supports signed coding.
Larger companies and organizations are, or should be, concerned about their system security. Maybe the most important piece of the security model is to have a well defined security policy. In this policy there should be a paragraph on Java.
Firewalls [9] are often used to implement parts of a organizations security policy. Restrictions can be setup for certain types of traffic as well as for individual or groups of hosts.
Traditionally the only way to regulate the use of Java is to enable/disable it in each users browser. There are a number of disadvantages with this approach. First, the decision is left to the user. A user can enable Java again if it once was disabled my the system administrator. Or a new browser might be downloaded that allows Java by default. Second, it will also prevent users from using applets provided from trusted servers on both the internal network and the Internet.
Another way to regulate traffic containing Java is at the firewall. One approach is to block all Java applets from the Internet and only allow users to access Java applets from servers on the internal network. How to block Java efficiently is discussed in Martin et. al.'s paper "Blocking Java applets at the firewall" [10].
A product called Surfingate released by Finjan Inc. uses a more advanced method according to their press release [11].
Finjan describes one of Surfingate's features as "A break through technology that scans on-the-fly applets and creates Applet Security Profile (ASP) which includes a description of all security risks posed by the current applet". I find this product feature very interesting since it is able to detect "all security risks". It must be a major breakthrough in computer science if one program can figure out exactly what another one is up to!
None of these methods are satisfactory if you want to allow some Java applets retrieved from the Internet but not all. Unless you are willing to rely on filtering technique to decide if a applet is dangerous for you or not.
At the 9th of December 1996 Sun released a new version of Java Developers Kit (JDK), called JDK 1.1. One enhancement of big importance was made to the component called the Security Manager [12]. The new Security Manager allows any downloaded applet sign by a trusted entity to run with the same full rights as local applications. That, is such applets are not subject to the "sandbox" restrictions of the original Java security model.
Also included in JDK 1.1 is a new security API. The new API adds functionality to handle digital signatures, message digests [13], key management, access control lists and more.
JDK 1.1 is currently in Beta release 3.
My intention is to present a new approach to manage the security problems associated with Java in a large network build on the new functionality in JDK 1.1. I want to regulate the Java traffic by identifying applets at the firewall and only allow applets that confirms with approved originators. This approach does not rely on filtering technique to be accurate nor does it block all Java traffic.
With this technique the security of a corporate network will lay in the hands of the system administrator not the users.
My thesis will include the following activities:
The major components of the Java applet authentication system are:
The Java authentication system is meant to be integrated into a complete firewall solution.
This is how it is supposed to work:
A popular collection of firewall proxy-servers with public available source code is the fwtk (FireWall Tool Kit) [14] from Trusted Information Systems Inc.. The fwtk includes a http-proxy component that can be modified to provide support for Java applet detection. The fwtk software only exists for UNIX operating systems. I will run fwtk on a Hewlett-Packard B132 with HP-UX 10.20. This machine is the proxy-server.
The authentication server's main task will be to check digital signatures and certificates against a database containing signatures that conforms with the corporate security policy. To be able to retrieve digital signatures from downloaded Java code API's in JDK 1.1 must be used. This limits the choice of platform since JDK 1.1 only is available for 32-bit Windows and Sun Solaris for Sparc systems. I choose to use a Windows NT 4.0 based system for my implementation.
I will test the reliability of the Java authentication system using a collection of both digitally signed and unsigned applets. Most applets will be public available, for easy reference.
The design of the Java authentication system will be documented. A protocol system will be designed and developed on the HP systems and a demo system will be installed on the research PCs at UCCS. Performance data and lessons learned in the two systems will be reported in the thesis.
| [1] | Ed Anuff, The Java Sourcebook, John Wiley & Sons, 1996 |
| [2] | JavaSoft, FAQ,- Applet Security http://java.sun.com/sfaq/index.html |
| [3] | Drew Dean, Edward W. Felten, Dan S. Wallach, Java Security: From HotJava to Netscape and Beyond, 1996 IEEE Symposium on Security and Privacy |
| [4] | David Hopwood, http://www.users.zetnet.co.uk/hopwood/java/bugs |
| [5] | Edward W. Felten , Dirk Balfanz, Drew Dean, Dan S. Wallach, Web Spoofing: An Internet Con Game, Technical Report 540-96, Department of Computer Science, Princeton University |
| [6] | Hostile Applets Homepage, http://www.math.gatech.edu/~mladue/HostileApplets.html |
| [7] | DigiCrime, http://www.digicrime.com/ |
| [8] | Corel Corporation, Corel Office for Java, http://officeforjava.corel.com/faq.htm |
| [9] | Marcus J. Ranum, Internet Firewalls FAQ, http://www.v-one.com |
| [10] | David M. Martin Jr., Sivaramakrishnan Rajagopalan, Aviel D. Rubin, Blocking Java Applets at the Firewall, Internet Society Symposium on Network and Distributed System Security, 1997 |
| [11] | Finjan Inc., Announcement - first Java firewall - SurfinGate, http://www.finjan.com, 18 November 1996 |
| [12] | Javasoft, Security in JDK 1.1, http://java.sun.com |
| [13] | RSA Data Security Inc., Frequently Asked Questions about todays Cryptography 3.0, http://www.rsa.com/rsalabs |
| [14] | Trusted Information Systems, FireWall Tool Kit (fwtk), http://www.tis.com |