A Java Filter

Dirk Balfanz Edward W. Felten

Princeton University Princeton University
[email protected] [email protected]

Abstract it wants.
Java has taken a different approach to mobile code se-
Rogue Java applets are currently a major concern for big curity. The Java platform is designed in such a way that
companies and private users alike. While the best protec- all system calls made by a Java program (Java applet) must
tion against them is to turn off Java support in the WWW be routed through a security manager, which can decide
browser, this “solution” is unsatisfying: it deprives users of whether or not certain sensitive operations should be al-
many of the advantages of the Java platform. Other mech- lowed. In the past, the security manager would deny ap-
anisms such as firewalls and code signing have been pro- plets almost any operations that would give them access to
posed to “enhance” security. In this paper we argue that the local system or the network, except to the network host
these mechanisms cannot deliver the security they promise. they were loaded from. This had the effect that Java applets
As an alternative, we describe a simple yet effective way would be executed in a “sandbox” which they could not
to prevent untrusted applets from entering the user’s com- leave. Recently, the security manager has been augmented
puter. At the same time, we allow trusted applets to exe- with fine-grained access control mechanisms that allow it
cute in whatever sandbox the browser provides for them. to make decisions based on who signed the applet and/or
Our technique works by modifying Java class loaders and where it was loaded from [5, 9]. However, it is still the case
can be extended to provide fine-grained access control for that every security-relevant system call is routed through
Java applets. the security manager, and that the security manager may
deny invocation of the respective system call. Breaking
Java security, then, means being able to access the system
1 Introduction (by bypassing the security manager or some other means)
when the security policy would have forbidden that access.
One especially interesting topic in the realm of Inter-
Again, due to implementation errors, oversights, or de-
net security is that of mobile code. While users browse the
sign flaws, ways have been found to break Java security.
World Wide Web, programs — known variously as applets,
The seriousness of possible attacks ranged from unautho-
controls, or scripts — are downloaded onto their comput-
rized network access to the ability to call any system call,
ers as part of Web pages they are viewing. The result is
thus completely exposing the system [3, 6]. All in all,
that untrusted programs are run on the user’s machine. The
there have been at least six flaws in various Java versions
system must protect the user against programs that have
that would have allowed an attacker to completely defeat
hostile intentions. For example, the mobile programs must
the security of the Java Virtual Machine. While all of
be prevented from reading personal information or altering
the reported bugs were fixed promptly, often within a few
the system’s state.
days, the threat of malicious Java applets that might exploit
This is why mobile code technologies such as ActiveX
undiscovered security holes remains.
[1] provide a line of defense: before downloading the mo-
bile code, the user is asked whether or not she really wants Java also suffers from “denial-of-service” attacks, in
to install the software in question. The code can be digi- which an applet does not penetrate the system but merely
tally signed to give the user some evidence as to who wrote crashes it or makes it unusable. This is often done via al-
(or endorsed) it. Security “breaches” of ActiveX take two lowed operations (ones permitted by the security manager),
forms: either the user is tricked into accepting hostile code, for example by opening 50 windows per second until the
or an ActiveX program can (by exploiting some sort of im- window manager software dies. Denial-of-service attacks
plementation error or oversight) transport itself onto the do not constitute a breach of security, but they are a con-
user’s system without the user’s consent. Once an Ac- cern for users. So far, no commercial Java system has pro-
tiveX control is installed on a machine, it can do whatever visions against denial-of-service attacks.

1
1.1 Approaches to Java Security

There are two basic strategies for protecting Java users

against malicious applets: strengthen the sandbox, or pre-
vent potentially hostile applets from running.
Strengthening the sandbox means improving the design
and implementation of the Java system, including formal
work to increase assurance by proving the foundations of
the system to be sound. While much valuable work (e.g.
[4, 2]) follows this approach, it does not solve the problem
for everybody. There are two reasons for this. First, while Figure 1: A firewall has to block all Java code, while per-
most users are comfortable with the current level of assur- mitting other data.
ance, some are not. Second, preventing the full range of
possible denial of service attacks is a very difficult prob- should be deployed, this would unfortunately also mean
lem that is probably beyond the current state of the art. that the company or agency decides against employing use-
The second approach is to stop potentially hostile ap- ful Java technology altogether.
plets from running in the first place. It is easy to do this by
While switching off Java support is an effective way
turning off Java entirely, but this prevents even the safest
to protect oneself from malicious applets, it is no solution
locally-developed applets from running. A midway point
for someone who wants to use Java technology in their in-
is to attempt to “filter” applets based on their origin or on
tranets.
who has digitally signed them. This is the approach we
follow.
2.2 Firewalls
Many applet filtering mechanisms have been proposed,
but, as we will explain below, many of them are overly
complex or are effective only against the most obvious at- Usually, companies find Java applet technology very
tacks. In this paper we will present a simple and effective useful for building WWW frontends to legacy systems,
applet filtering mechanism which we have implemented for group ware, and other things that are used within the in-
Netscape Navigator 3.x and Microsoft Internet Explorer tranet. These applets are written, and used, within the com-
3.x. pany. They are trusted not to be vicious. On the other hand,
The paper is structured as follows: in Section 2 we there is a great number of untrusted applets out there on
will describe current methods for protecting systems from the Internet, written by people and with intentions that we
Java applets, and discuss their shortcomings. Since our don’t know. It would be desirable to configure browsers so
method uses class loaders, in Section 3 we will give a brief that they accept applets from the company’s intranet, but
overview of how a Java class loader works. In Section 4 refuse to load applets from the Internet.
we will present our system, the Java Filter. One way to achieve this goal is to filter applets out at the
firewall (see Figure 1). Several firewall vendors ship Java
filtering technology (e.g [8]) as part of their firewalls. Un-
fortunately, these products cannot guarantee full protection
2 Protecting Your System (Not!)
from unwanted applets as it is very hard to detect every ap-
2.1 Switching off Java plet that tries to sneak its way through the firewall. Here
are a few techniques that try to detect Java applets at the
Whenever people find a new security hole in the Java firewall and ways to circumvent them:
system, they usually recommend to switch off Java support
in Web browsers until the bug is fixed. This is in fact an The first idea is to look for Java class files. They can
effective way to protect the user’s system: Switching off be recognized by a magic byte sequence that is re-
Java support has the effect that Java applets will not be quired at the beginning of every class file.
fetched from across the network and installed on the local Pitfall: Java class files may come as part of an com-
machine. Malicious applets can therefore cause no harm pressed archive (e.g. Jar or Cab files). Due to the na-
whatsoever. ture of compression, nothing in the archive (not nec-
Alas, switching off Java support of course has an impor- essarily even its name) exposes the fact that it con-
tant side-effect: It switches off Java support! If a company tains Java class files. Class files that are part of an
or government agency decides that Java applets are poten- archive cannot be detected by this technique. In addi-
tially harmful and that an effective measure against them tion, class files may be passed via an encrypted (SSL)

2
 connection, which will make them indistinguishable
from ordinary files to the firewall.

Java class files can be recognized by their name,

which will end in “.class”.
Pitfall: Depending on the browser, this may either
not be the case or, again, be circumvented by sending
applets as part of an archive.

HTML pages can be rewritten at the firewall so that

no “Applet” tags are left in the HTML file. This Figure 2: The normal workings of a class loader.
will have the effect that the browser will never ask for
an applet to be fetched across the firewall. 3 Class Loaders
Pitfall: Javascript can be used to build Applet tags
on the fly. Although there is no Applet tag in the In this paper we will present a system that allows users
HTML file, the browser’s executing of Javascript will who surf the World Wide Web to selectively “switch off”
cause it to be inserted at the time the page is viewed. Java support in their browsers. For untrusted applets, this
will be as effective as the solution discussed in Section 2.1,
2.3 Code Signing but trusted applets can still be used. Since our system uses
the Java class loader, we will here give a brief overview
about what a class loader is and how it works.
When Sun Microsystems and the major browser com-
In Java, linking is done at runtime. Whenever execution
panies switched from the simple sandbox security model
of Java bytecode requires the presence of a new class (e.g.
to fine-grained access control based on signed code, they
because one of its methods is invoked), then a class loader
sometimes tried to give the impression that this would ”en-
is invoked to fetch the class material (the class file). It is
hance” security. Code signing cryptographically binds a
up to the class loader how to get the class material. Once
certain principal, such as an individual or company, to a
fetched, the class is added to the runtime system and can
piece of code. It is not feasible to change a signed piece of
then be used by the Java program.
code without being detected, nor is it possible to imperson-
WWW browsers have special class loaders, so-called
ate someone else by augmenting code with their signature.
applet class loaders. When an Applet tag is encountered
With this technology in place, it is always possible to
on a Web page, a new applet class loader is created for that
find out who signed the code. The argument goes that now
applet. Whenever a new class needs to be linked into the
users can decide that code signed by untrusted or unknown
system, the applet class loader will first try and load the
parties should be denied privileges.
class from the local CLASSPATH. Only if it doesn’t find
However, the browser will still load “untrusted” code,
the class locally, it will go to the origin of the applet and
the difference is only that the untrusted code will run with
fetch the class material across the network. The first class
fewer privileges. Untrusted code is usually run within the
that it fetches is the class mentioned in the Applet tag of
old sandbox (i.e. no file system access, no network access
the HTML page.
except back to the originating host). But we have already
Figure 2 summarizes how a class loader works: When
seen that code can exploit implementation bugs and break
an applet is detected as part of a Web page, an applet
out of that sandbox. Code signing provides no enhanced
class loader is created that subsequently has to load all
security at this point.
the classes for that applet, either from the local system or
Even worse, code signing introduces new system code
across the network.
which can have, and in fact has been found to have , new
bugs that weren’t there before. This opens even more
doors for malicious applets. On the trade-off continuum
between security and functionality, code signing belongs
4 Guarding the Door
on the functionality side, as it can be used to provide fine
4.1 How it Works
grained access control and provides the user with informa-
tion about who endorsed a specific piece of code. Code Our system is very simple: We prevent the creation of
signing does not “enhance” security.
This is not quite correct. If there already was an applet on the same
see http: page that came from the same place as the new applet, its class loader can
//www.cs.princeton.edu/sip/news/april29.html be used.

3
 Action URL
allow http://www.javasoft.com:80/applets/WordMatch/
deny http://www.javasoft.com/
allow http://www.packet.com/java/hotwired/
deny http://www.earthweb.com/java/Thingy/
deny http://www.cruzio.com/˜sabweb/arcade/

Figure 4: A sample list of URLs.

We therefore maintain a simple ordered list of URLs

and whether or not applets from that URL should be down-
loaded. Figure 4 shows an example. The guard object will
go down the list and compare the URL of the applet that is
about to be created with the URLs in the list. If it finds
a match, then it applies the specified action. Note that
the URLs in the list cover all their subdirectories. In our
example, an applet from http://www.packet.com/
java/hotwired/news/ would be allowed because of
the third entry in the list. Also note that in our example, all
applets from http://www.javasoft.com/ would be
denied except those from http://www.javasoft.
Figure 3: A guard object decides whether or not to create com:80/applets/WordMatch/, because the list is
a class loader. processed from top to bottom.
The list of URLs is saved on the local file system and
thus preserved across browsing sessions. The file used for
a class loader for untrusted applets. Assume that we come
storing this list is human-readable and can be edited. For
across an Applet tag on a Web page. The runtime system
example, we could specify that all applets from within the
will try to create a class loader for that applet by creating a
company are allowed, but no others, by saying something
new instance of class AppletClassLoader. One of the
like this:
arguments passed to that call is the URL of the applet. If allow http://www.mycompany.com/
the applet class loader decides that this URL is untrusted, it deny http://
can then throw an exception. We note that this exception is deny ftp://
thrown during the creation of the class loader. This has the deny https://
effect that the class loader will not be created at all. When
Since the last three lines match any possible applet
there is no class loader, no-one can fetch classes across the
only applets from http://www.mycompany.com/
network. We see that for untrusted applets this is as effec-
will be allowed on the machine.
tive as switching off Java support altogether: The remote
classes don’t even enter the local system. For trusted ap-
plets, our class loader works as before.
4.2 How it looks
Figure 3 shows how the system works: We introduce
a “guard” object that has the task of deciding whether or What if none of the URLs in the list match the given ap-
not a given URL is trusted. During creation of the class plet? Then some user intervention is necessary. As with all
loader, the guard object is consulted, which may or may security relevant software, the design of the graphical user
not cause an exception to be thrown. If no exception is interface is crucial. We don’t want users to be annoyed by
thrown, the class loader just works like before. If an ex- windows popping up too often to warn them about poten-
ception is thrown, then the creation of the class loader fails. tial security risks. Also, we want to make is easy for the
This corresponds to there being no class loader at all in the non-expert to make security-relevant decisions, while giv-
picture. ing the expert full control over the system.
When we first come across an applet that doesn’t match
We only distinguish between “trusted” and “untrusted”
any URL in the list, the dialog shown in Figure 5 will pop
URLs since our goal is binary as well: We either want to
load the applet (and subject it to whatever security policies Depending on what browser is used, more protocols like gopher:
the browser provides) or we don’t want to load it at all. etc. may have to be included.

4
Figure 5: This dialog that pops up when an unknown applet Figure 6: Advanced version of the dialog.
is discovered.
list.
up. It displays the URL the applet is about to be loaded
from, and asks to answer two questions: First, we have to 4.3 Implementation
decide whether or not we want this applet to run on our
machine. The default is not to run the applet. Second, we We implemented the Java Filter for Netscape Naviga-
should decide whether that decision is to be “remembered” tor 3.0 and Microsoft Internet Explorer 3.0 on the Win-
for the future, i.e. whether the URL should be included in dows platform. Most of the code could be shared, although
the file that is saved for future use. The default is not to access to the Windows registry and file system (for sav-
remember that decision, which will cause the browser to ing the list of URLs) turned out to be slightly different on
ask the same question again if and when we visit the same each platform. The solution is not “100% pure”, since we
applet during a future session. During a browser session, needed native methods to access file system and Windows
we will usually not be asked again for a specific applet. If registry in Navigator and used Microsoft-specific classes
we choose to make the settings permanent, then the applet for Internet Explorer. The installation, which can be down-
in question will always be allowed on our system (or be loaded from our Web site, will change the applet class
denied entrance - depending on what we chose) - unless loader of the installed browsers and add necessary classes
or until we manually change the file that holds the list of to the class library.
URLs.
We can have more advanced control over which ap- 4.3.1 Changing the Class Library
plets should be allowed into our system, and which applets
How did we change the browser’s class library, in partic-
should be blocked. When we click on the ”Advanced” tab
ular the class loader so that it employs our guard object?
bar, the dialog changes to what we see in Figure 6.
Remember that we do not have source code of the class
The upper half of the dialog lets us answer the same loader. There are several ways to do this:
questions that we saw in the “easy” version. The field
displaying the URL is now editable. We can change One obvious way is to extract the class loader from the
this URL to whatever we like: If we come across class library, decompile, change the Java code, com-
an applet from http://java.sun.com/applets/ pile it, and inject it back into the class library (which is
WordMatch/ we can decide that we trust all applets from a ZIP file). This has some legal issues (which we will
JavaSoft and edit the URL to show http://java.sun. not address in this paper) and is also difficult: A num-
com/. This edited URL, and not the original one, will be ber of decompilers that we tested would either fail on
included in the list of URLs against which the guard object the task of decompiling the class loader or produce
checks applet URLs. obviously incorrect code. However, if a decompiler is
The lower half of the dialog shows the URLs known so available that does the job, this is a valid measure.
far to the system, and whether or not we allowed access
Since our changes to the class loader are minimal (we
for them. Since the list of URLs is searched from top to
basically add one line of code in the constructor) we
bottom, the order in which the URLs occur matters. The
user can change the priority of the current URL within that http://www.cs.princeton/sip/

5
 could theoretically change the class file directly. Al- 6 Related Work
though we only add a few bytecode instructions, we
need a program that can parse and write class files: In Section 2 we saw which measures are sometimes
Injecting only a few bytecode instructions can cause taken to “enhance” security. However, we also saw that
complex changes in the class file (e.g. constant pool, these measures are either inconvenient or not effective. Mi-
attributes). crosoft has recently included the notion of security zones
in their Internet Explorer [7]. Depending on what security
One technique that we used is to make trivial changes
zone an applet comes from, it can run with more or less
to the class file of the AppletClassLoader
privileges. Unlike the systems that Netscape and Sun de-
to the effect that the class file then repre-
veloped, the settings for a security zone can actually spec-
sents a class of a different Name (for example
ify that Java code should not be downloaded at all.
XppletClassLoader). Then we create a new
This makes Microsoft’s system very similar to our Java
Java class, called AppletClassLoader that sub-
Filter, except that Microsoft’s system is bigger and in-
classes the original AppletClassLoader (now
cludes more features. On the other hand, the concepts and
XppletClassLoader). In its constructor it calls
tools presented in this paper are simple and general enough
the original constructor and the guard object (which
to be applied almost without changes to any type of appli-
may or may not throw an exception). Since we in-
cation that executes remote Java code.
herit all non-private methods, to the runtime system
the new class is a perfectly valid applet class loader. We also note that the concept of using class loaders
to control Java security can be extended to provide fine-
The other classes that are needed for the Java Filter can grained access control. Instead of blocking the applet, we
just be added to the class library. could (again, by using class loaders) block certain system
We note that these techniques can be used to enable classes from being linked against the applet, thus denying
Java filtering not only for mainstream Web browsers, but access to certain parts of the system. See [9] for details on
also for other types of (Java) applications that execute Java this.
applets but want to be protected from attacks exploiting
weaknesses in the Java implementation.
7 Conclusion
5 Future Work We presented a simple, yet effective protection against
untrusted Java applets that doesn’t have many of the short-
Since the Java Filter is not a pure Java implementation,
comings of other possible approaches. We implemented
ports to other platforms like the Macintosh or UNIX re-
the design and have made available a copy for public down-
quire additional work. Feedback we got from users who
load.
downloaded the Java Filter suggested that we should write
versions of the Java Filter for those platforms.
Also, the current URL pattern matching is not very so-
phisticated. Sometimes companies have many Web servers Acknowledgements
and would like to have a line like this in their URL list:
allow http://*.mycompany.com/ Our work is supported by donations from Sun Mi-
We are looking into providing support for regular ex- crosystems, Bellcore, Microsoft, and Merrill Lynch. Ed-
pressions for that purpose. ward Felten is supported in part by an NSF National Young
In recent versions of their browsers, Netscape and Mi- Investigator award.
crosoft have included code signing and features that are
similar to what the Java Filter offers. We still believe that
not downloading classes in the first place is the best protec- References
tion against malicious Java applets. However, we are not
certain whether a version of the Java Filter for the latest [1] Microsoft Corporation. Proposal for authenticating
versions of Navigator and Internet Explorer is desirable (or code via the internet. http://www.microsoft.
feasible, for that matter: the class libraries are now signed com/security/tech/authcode/
and can no longer be easily altered). authcode-f.htm, April 1996.
This turned out to be valid only for Internet Explorer. In Netscape this
technique did not work, presumably because the runtime system relies on [2] Drew Dean. The security of static typing with dynamic
certain specific internals of the class loader like private fields etc. linking. In Fourth ACM Conference on Computer and

6
 Communications Security, Zurich, Switzerland, April
1997.
[3] Drew Dean, Edward Felten, and Dan Wallach. Java
security: From HotJava to Netscape and beyond. In
Proceedings of 1996 IEEE Symposium on Security and
Privacy, Oakland, California, May 1996.
[4] S. Drossopoulou and S. Eisenbach. Java is type safe –
probably. In Proceedings of the Eleventh European
Conference on Object-Oriented Programming, June
1997.

[5] Li Gong and Roland Schemers. Implementing pro-

tection domains in the Java Development Kit 1.2.
In The Internet Society Symposium on Network and
Distributed System Security, San Diego, California,
March 1998. Internet Society.
[6] Gary McGraw and Edward Felten. Java Security: Hos-
tile Applets, Holes, and Antidotes. John Wiley and
Sons, 1996.
[7] Microsoft Corporation, Redmond, Washington. Mi-
crosoft Security Management Architecture White Pa-
per, May 1997. http://www.microsoft.com/
ie/security/ie4security.htm.
[8] Finjan Soft-
ware. SurfinGate. http://www.finjan.com/
products/html/surfingate.html.
[9] D. S. Wallach, D. Balfanz, D. Dean, and E. W. Felten.
Extensible security architectures for Java. In Proceed-
ings of the 16th ACM Symposium on Operating Sys-
tems Principles, Saint-Malo, France, October 1997.