Java Security: Web Browsers and Beyond
`
`Drew Dean
`ddean@cs.princeton.edu
`
`Edward W. Felten
`Dan S. Wallach
`felten@cs.princeton.edu
`dwallach@cs.princeton.edu
`Department of Computer Science
`Princeton University
`Princeton, NJ 08544
`
`Dirk Balfanz
`balfanz@cs.princeton.edu
`
`February 24, 1997
`
`Abstract
`
`The introduction of Java applets has taken the World Wide Web by storm. Java allows web creators
`to embellish their content with arbitrary programs which execute in the web browser, whether for sim-
`ple animations or complex front-ends to other services. We examined the Java language and the Sun
`HotJava, Netscape Navigator, and Microsoft Internet Explorer browsers which support it, and found a sig-
`nificant number of flaws which compromise their security. These flaws arise for several reasons, including
`implementation errors, unintended interactions between browser features, differences between the Java
`language and bytecode semantics, and weaknesses in the design of the language and the bytecode format.
`On a deeper level, these flaws arise because of weaknesses in the design methodology used in creating
`Java and the browsers. In addition to the flaws, we discuss the underlying tension between the openness
`desired by web application writers and the security needs of their users, and we suggest how both might
`be accommodated.
`
`1 Introduction
`
`The continuing growth and popularity of the Internet has led to a flurry of developments for the World
`Wide Web. Many content providers have expressed frustration with the inability to express their ideas in
`HTML. For example, before support for tables was common, many pages simply used digitized pictures of
`tables. As quickly as new HTML tags are added, there will be demand for more. In addition, many content
`providers wish to integrate interactive features such as chat systems and animations.
`Rather than creating new HTML extensions, Sun Microsystems popularized the notion of downloading
`a program (called an applet) which runs inside the web browser. Such remote code raises serious security
`issues; a casual web reader should not be concerned about malicious side-effects from visiting a web page.
`Languages such as Java[21], Safe-Tcl[6], Phantom[10], Juice[14] and Telescript[16] have been proposed for
`running untrusted code, and each has varying ideas of how to thwart malicious programs.
`After several years of development inside Sun Microsystems, the Java language was released in mid-
`1995 as part of Sun’s HotJava web browser. Shortly thereafter, Netscape Communications Corp. announced
`they had licensed Java and would incorporate it into their Netscape Navigator web browser, beginning
`with version 2.0. Microsoft has also licensed Java from Sun, and incorporated it into Microsoft Internet
`Explorer 3.0. With the support of many influential companies, Java appears to have the best chance of be-
`coming the standard for executable content on the web. This also makes it an attractive target for malicious
`attackers, and demands external review of its security.
`The original version of this paper was written in November, 1995 — after Netscape announced it would
`use Java. Since that time, we have found a number of bugs in Navigator through its various beta releases
`and later in Microsoft’s Internet Explorer. As a direct result of our investigation, and the tireless efforts of
`the vendors’ Java programmers, we believe the security of Java has significantly improved since its early
`days. In particular, Internet Explorer 3.0, which shipped in August, 1996, had the benefit of nine months
`
`1
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 1
`
`

`
`of our investigation into Netscape’s Java. Still, despite all the work done by us and by others, no one can
`claim that Java’s security problems are fixed.
`Netscape Navigator and HotJava1 are examples of two distinct architectures for building web browsers.
`Netscape Navigator is written in an unsafe language, C, and runs Java applets as an add-on feature. Hot-
`Java is written in Java itself, with the same runtime system supporting both the browser and the applets.
`Both architectures have advantages and disadvantages with respect to security: Netscape Navigator can
`suffer from being implemented in an unsafe language (buffer overflow, memory leakage, etc.), but pro-
`vides a well-defined interface to the Java subsystem. In Netscape Navigator, Java applets can name only
`those functions and variables explicitly exported to the Java subsystem. HotJava, implemented in a safe
`language, does not suffer from potential memory corruption problems, but can accidentally export private
`browser state to applets.
`In order to be secure, such systems must limit applets’ access to system resources such as the file sys-
`tem, the CPU, the network, the graphics display, and the browser’s internal state. The language should
`be memory safe – preventing forged pointers and checking array bounds. Additionally, the system should
`garbage-collect memory to prevent both malicious and accidental memory leakage. Finally, the system
`must manage system calls and other methods which allow applets to affect each other as well as the envi-
`ronment beyond the browser.
`Many systems in the past have attempted to use language-based protection. The Anderson report[2]
`describes an early attempt to build a secure subset of Fortran. This effort was a failure because the imple-
`mentors failed to consider all of the consequences of the implementation of one construct: assigned GOTO.
`This subtle flaw resulted in a complete break of the system. Jones and Liskov describe language support
`for secure dataflow[26]. Rees describes a modern capability system built on top of Scheme[40].
`The remainder of this paper is structured as follows. Section 2 discusses the Java language in more
`detail, Section 3 gives a taxonomy of known security flaws in Sun’s HotJava, Netscape’s Navigator, and
`Microsoft’s Internet Explorer web browsers, Section 4 considers how the structure of these systems con-
`tributes to the existence of bugs, Section 5 discusses the need for flexible security in Java, and Section 6
`presents our conclusions. A more complete discussion of some of these issues can be found in McGraw and
`Felten’s book[34].
`
`2 Java Semantics
`
`Java is similar in many ways to C++[42]. Both provide support for object-oriented programming, share
`many keywords and other syntactic elements, and can be used to develop standalone applications. Java
`diverges from C++ in the following ways: it is type-safe, supports only single inheritance (although it
`decouples subtyping from inheritance), and has language support for concurrency. Java supplies each class
`and object with a lock, and provides the synchronized keyword so each class (or instance of a class, as
`appropriate) can operate as a Mesa-style monitor[30].
`Java compilers produce a machine-independent bytecode, which may be transmitted across a network
`and then interpreted or compiled to native code by the Java runtime system. In support of this downloaded
`code, Java distinguishes remote code from local code. Separate sources2 of Java bytecode are loaded in
`separate name spaces to prevent both accidental and malicious name clashes. Bytecode loaded from the
`local file system is visible to all applets. The documentation[22] says the “system name space” has two
`special properties:
`
`1. It is shared by all “name spaces.”
`
`2. It is always searched first, to prevent downloaded code from overriding a system class.
`
`1Unless otherwise noted, “HotJava-Alpha” refers to the 1.0 alpha 3 release of the HotJava web browser from Sun Microsystems,
`“Netscape Navigator” refers to Netscape Navigator 2.0, “Internet Explorer” refers to Microsoft Internet Explorer 3.0, and “JDK” refers
`to the Java Development Kit, version 1.0, from Sun.
`2While the documentation[22] does not define “source”, it appears to mean the URL prefix of origin. Sun and Netscape have
`announced plans to include support for digital signatures in future versions of their products. Microsoft has some support for digital
`signatures. See section 5.4.
`
`2
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 2
`
`

`
`However, we have found that the second property does not hold.
`The Java runtime system knows how to load bytecode only from the local file system. To load code
`from other sources, the Java runtime system calls a subclass of the abstract class3 ClassLoader, which
`defines an interface for the runtime system to ask a Java program to provide a class. Classes are transported
`across the network as byte streams, and reconstituted into Class objects by subclasses of ClassLoader.
`Each class is internally tagged with the ClassLoader that loaded it, and that ClassLoader is used to
`resolve any future unresolved symbols for the class. Additionally, the SecurityManager has methods to
`determine if a class loaded by a ClassLoader is in the dynamic call chain, and if so, where. This nesting
`depth is then used to make access control decisions in JDK 1.0.x and derived systems (including Netscape
`Navigator and Internet Explorer).
`Java programmers can combine related classes into a package. These packages are similar to name
`spaces in C++[43], modules in Modula-2[44], or structures in Standard ML[35]. While package names con-
`sist of components separated by dots, the package name space is actually flat: scoping rules are not related
`to the apparent name hierarchy. In Java, public and private have the same meaning as in C++: Public
`classes, methods, and instance variables are accessible everywhere, while private methods and instance
`variables are only accessible inside the class definition. Java protected methods and variables are acces-
`sible in the class or its subclasses or in the current (package, origin of code) pair. A (package, origin of code)
`pair defines the scope of a Java class, method, or instance variable that is not given a public, private, or
`protected modifier4. Unlike C++, protected variables and methods can only be accessed in subclasses
`when they occur in instances of the subclasses or further subclasses. For example:
`class Foo {
`protected int x;
`void SetFoo(Foo obj) { obj.x = 1; } // Legal
`void SetBar(Bar obj) { obj.x = 1; } // Legal
`
`} c
`
`lass Bar extends Foo {
`void SetFoo(Foo obj) { obj.x = 1; } // Illegal
`void SetBar(Bar obj) { obj.x = 1; } // Legal
`
`} T
`
`he definition of protected was the same as C++ in some early versions of Java; it was changed during
`the beta-test period to patch a security problem[37] (see also section 4.2).
`The Java bytecode runtime system is designed to enforce the language’s access semantics. Unlike C++,
`programs are not permitted to forge a pointer to a function and invoke it directly, nor to forge a pointer to
`data and access it directly. If a rogue applet attempts to call a private method, the runtime system throws
`an exception, preventing the errant access. Thus, if the system libraries are specified safely, the runtime
`system is designed to ensure that application code cannot break these specifications.
`The Java documentation claims that the safety of Java bytecodes can be statically determined at load
`time. This is not entirely true: the type system uses a covariant[7] rule for subtyping arrays, so array stores
`require run time type checks5 in addition to the normal array bounds checks. Cast expressions also require
`runtime checks. Unfortunately, this means the bytecode verifier is not the only piece of the runtime system
`that must be correct to ensure type safety. Dynamic checks also introduce a performance penalty.
`3An abstract class is a class with one or more methods declared but not implemented. Abstract classes cannot be instantiated,
`but define method signatures for subclasses to implement.
`4Colloquially, methods or variables with no access modifiers are said to have package scope.
`5For example, suppose that A is a subtype of B; then the Java typing rules say that A[] (“array of A”) is a subtype of B[]. Now the
`following procedure cannot be statically type-checked:
`void proc(B[] x, B y)
`x[0] = y;
`
`Since A[] is a subtype of B[], x could really have type A[]; similarly, y could really have type A. The body of proc is not type-safe
`if the value of x passed in by the caller has type A[] and the value of y passed in by the caller has type B. This condition cannot be
`checked statically.
`
`3
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 3
`
`

`
`2.1 Java Security Mechanisms
`
`In HotJava-Alpha, all of the access controls were done on an ad hoc basis which was clearly insufficient.
`The beta release of JDK introduced the SecurityManager class, meant to be a reference monitor[29]. The
`SecurityManager defines and implements a security policy, centralizing all access control decisions. All
`potentially dangerous methods first consult the security manager before executing. Netscape and Microsoft
`also use this architecture.
`When the Java runtime system starts up, there is no security manager installed. Before executing un-
`trusted code, it is the web browser’s or other user agent’s responsibility to install a security manager. The
`SecurityManager class is meant to define an interface for access control; the default SecurityManager
`implementation throws a SecurityException for all access checks, forcing the user agent to define and
`implement its own policy in a subclass of SecurityManager. The security managers in current browsers
`typically make their access control decisions by examining the contents of the call stack, looking for the
`presence of a ClassLoader, indicating that they were called, directly or indirectly, from an applet.
`Java uses its type system to provide protection for the security manager. If Java’s type system is sound,
`then the security manager should be tamperproof. By using types instead of separate address spaces for
`protection, Java is more easily embeddable in other software, and potentially performs better because pro-
`tection boundaries can be crossed without a context switch[3].
`
`3 Taxonomy of Java Bugs
`
`We now present a taxonomy of known Java bugs, past and present. Dividing the bugs into classes is useful
`because it helps us understand how and why they arose, and it alerts us to aspects of the system that may
`harbor future bugs.
`
`3.1 Denial of Service Attacks
`
`Java has few provisions to thwart denial of service attacks. The obvious attacks are busy-waiting to con-
`sume CPU cycles and allocating memory until the system runs out, starving other threads and system pro-
`cesses. Additionally, an applet can acquire locks on critical pieces of the browser to cripple it. For example,
`the code in figure 1 locks the status line at the bottom of the HotJava-Alpha browser, effectively preventing
`it from loading any more pages. In Netscape Navigator, this attack can lock the java.net.InetAddress
`class, blocking all hostname lookups and hence most new network connections. HotJava, Navigator, and
`Internet Explorer all have classes suitable for this attack. The attack could be prevented by replacing such
`critical classes with wrappers that do not expose the locks to untrusted code. However, the CPU and mem-
`ory attacks cannot be easily fixed; many genuine applications may need large amounts of memory and
`CPU. Another attack, first implemented by Mark LaDue, is to open a large number of windows on the
`screen. This will sometimes crash the machine. LaDue has a web page with many other denial of service
`attacks[28].
`There are two twists that can make denial of service attacks more difficult to cope with. First, an attack
`can be programmed to occur after some time delay, causing the failure to occur when the user is viewing
`a different web page, thereby masking the source of the attack. Second, an attack can cause degradation
`of service rather than outright denial of service. Degradation of service means significantly reducing the
`performance of the browser without stopping it. For example, the locking-based attack could be used to
`hold a critical system lock most of the time, releasing it only briefly and occasionally. The result would be
`a browser that runs very slowly.
`
`synchronized (Class.forName("net.www.html.MeteredStream")) {
`while(true) Thread.sleep(10000);
`
`}
`
`Figure 1: Java code fragment to deadlock the HotJava browser by locking its status line.
`
`4
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 4
`
`

`
`Bob
`
`applet
`
`Charlie
`
`applet
`
`Web
`requests
`
`Alice
`
`covert
`channel
`
`Figure 2: A Three Party Attack — Charlie produces a Trojan horse applet. Bob likes it and uses it in his web
`page. Alice views Bob’s web page and Charlie’s applet establishes a covert channel to Charlie. The applet
`leaks Alice’s information to Charlie. No collusion with Bob is necessary.
`
`Sun has said that they consider denial of service attacks to be low-priority problems[20].
`
`3.2 Two vs. Three Party Attacks
`
`It is useful to distinguish between two different kinds of attack, which we shall call two-party and three-
`party. A two-party attack requires that the web server the applet resides on participate in the attack. A
`three-party attack can originate from anywhere on the Internet, and might spread if it is hidden in a useful
`applet that gets used by many web pages (see figure 2). Three-party attacks are more dangerous than
`two-party attacks because they do not require the collusion of the web server.
`
`3.3 Covert Channels
`
`Various covert channels exist in HotJava, Navigator, and Internet Explorer, allowing applets to have two-
`way communication with arbitrary third-parties on the Internet.
`Typically, most HotJava users will use the default network security mode, which only allows an applet
`to connect to the host from which it was loaded. This is the only security mode available to Navigator and
`Internet Explorer users6. In fact, the browsers have failed to enforce this policy through a number of errors
`in their implementation.
`The accept() system call, used to receive a network connection initiated on another host, is not pro-
`tected by the usual security checks in HotJava-Alpha. This allows an arbitrary host on the Internet to con-
`nect to a HotJava browser as long as the location of the browser is known. For this to be a useful attack, the
`applet needs to signal the external agent to connect to a specified port. Even an extremely low-bandwidth
`covert channel would be sufficient to communicate this information. The accept() call is properly pro-
`tected in current Java implementations.
`If the web server which provided the applet is running an SMTP mail daemon, the applet can connect
`to it and transmit an e-mail message to any machine on the Internet. Additionally, the Domain Name System
`(DNS) can be used as a two-way communication channel to an arbitrary host on the Internet. An applet
`may reference a fictitious name in the attacker’s domain. This transmits the name to the attacker’s DNS
`server, which could interpret the name as a message, and then send a list of arbitrary 32-bit IP numbers as
`a reply. Repeated DNS calls by the applet establish a channel between the applet and the attacker’s DNS
`server. This channel also passes through a number of firewalls[9]. In HotJava-Alpha, the DNS channel
`was available even with the security mode set to “no network access,” although this was fixed in later Java
`versions. DNS has other security implications; see section 3.5.1 for details.
`Another third-party channel is available with the URL redirect feature. Normally, an applet may instruct
`the browser to load any page on the web. An attacker’s server could record the URL as a message, then
`redirect the browser to the original destination.
`When we notified Sun about these channels, they said the DNS channel would be fixed[36], but in fact
`it was still available in JDK and Netscape Navigator. Netscape has since issued a patch (incorporated into
`
`6Without using digitally signed code.
`
`5
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 5
`
`

`
`Netscape Navigator 2.01) to fix this problem.
`As far as we know, nobody has done an analysis of covert storage or timing channels in the Java runtime
`system.
`
`3.4 Information Available to Applets
`
`If a rogue applet can establish a channel to any Internet host, the next issue is what the applet can learn
`about the user’s environment to send over the channel.
`In HotJava-Alpha, most attempts by an applet to read or write the local file system result in a dialog
`box for the user to grant approval. Separate access control lists (ACLs)7 specify where reading and writing
`of files or directories may occur without the user’s explicit permission. By default, the write ACL is empty
`and the read ACL contains the HotJava library directory and specific MIME mailcap files. The read ACL
`also contains the user’s public html directory, which may contain information which compromises the
`privacy of the user. The Windows 95 version additionally allows writing (but not reading) in the \TEMP
`directory. This allows an applet to corrupt files in use by other Windows applications if the applet knows
`or can guess names the files may have. At a minimum, an applet can consume all the free space in the file
`system. These security concerns could be addressed by the user editing the ACLs; however, the system
`default should have been less permissive. Navigator and Internet Explorer do not permit any file system
`access by applets (without digital signatures).
`In HotJava-Alpha, we could learn the user’s login name, machine name, as well as the contents of all
`environment variables; System.getenv() in HotJava-Alpha had no security checks. By probing envi-
`ronment variables, including the PATH variable, we could often discover what software is installed on the
`user’s machine. This information could be valuable either to corporate marketing departments, or to at-
`tackers desiring to break into a user’s machine. In later Java versions, System.getenv() was replaced
`with “system properties,” many of which are not supposed to be accessible by applets. However, there
`have been implementation problems (see Section 3.7.2) that allowed an applet to read or write any system
`property.
`Java allows applets to read the system clock, making it possible to benchmark the user’s machine. As a
`Java-enabled web browser may well run on pre-release hardware and/or software, an attacker could learn
`valuable information. Timing information is also needed for the exploitation of covert timing channels.
`“Fuzzy time”[25] should be investigated to see if it can mitigate these problems.
`
`3.5 Implementation Errors
`
`Some bugs arise from fairly localized errors in the implementation of the browser or the Java subsystem.
`
`3.5.1 DNS Weaknesses
`
`A significant problem appeared in the JDK and Netscape Navigator implementation of the policy that an
`applet can only open a TCP/IP connection back to the server it was loaded from. While this policy is
`reasonable, since applets often need to load components (images, sounds, etc.) from their host, it was not
`uniformly enforced. This policy was enforced as follows:
`
`1. Get all the IP-addresses of the hostname that the applet came from.
`
`2. Get all the IP-addresses of the hostname that the applet is attempting to connect to.
`
`3. If any address in the first set matches any address in the second set, allow the connection. Otherwise,
`do not allow the connection.
`
`The problem occurred in the second step: the applet can ask to connect to any hostname on the Internet, so
`it can control which DNS server supplies the second list of IP-addresses; information from this untrusted
`DNS server was used to make an access control decision. There is nothing to prevent an attacker from
`
`7While Sun calls these “ACLs”, they are actually profiles — a list of files and directories granted specific access permissions.
`
`6
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 6
`
`

`
`hotjava.props.put("proxyHost", "proxy.attacker.com");
`hotjava.props.put("proxyPort", "8080");
`hotjava.props.put("proxySet", "true");
`HttpClient.cachingProxyHost = "proxy.attacker.com";
`HttpClient.cachingProxyPort = 8080;
`HttpClient.useProxyForCaching = true;
`
`Figure 3: Code to redirect all HotJava-Alpha HTTP retrievals. FTP retrievals may be redirected with similar
`code.
`
`attacker.com
`
`hostname lookup
`
`DNS
`
`Firewall
`
`hostname
`lookup
`
`DNS
`
`victim.org
`
`User
`applet
`
`applet
`
`Web proxy
`
`applet
`
`applet exploits
`sendmail bug
`Internal mail
` server
`
`Trusted mail
` server
`
`information leak
`
`Web server
`
`Mail server
`
`Figure 4: DNS subversion of Java: an applet travels from attacker.com to victim.org through normal
`channels. The applet then asks to connect to foo.attacker.com, which is resolved by the DNS server
`for attacker.com to be mail server inside victim.org which can then be attacked.
`
`creating a DNS server that lies[4]. In particular, it may claim that any name for which it is responsible
`has any given set of addresses. Using the attacker’s DNS server to provide a pair of addresses (machine-
`to-connect-to, machine-applet-came-from), the applet could connect to any desired machine on the Internet.
`The applet could even encode the desired IP-address pair into the hostname that it looks up. This attack
`is particularly dangerous when the browser is running behind a firewall, because the malicious applet can
`attack any machine behind the firewall. At this point, a rogue applet can exploit a whole legion of known
`network security problems to break into other nearby machines.
`This problem was postulated independently by Steve Gibbons[17] and by us. To demonstrate this
`flaw, we produced an applet that exploits an old sendmail hole to run arbitrary Unix commands as user
`daemon.
`Sun (JDK 1.0.1) and Netscape (Navigator 2.01)8 have both issued patches to fix this problem.
`
`3.5.2 Buffer Overflows
`HotJava-Alpha had many unchecked sprintf() calls that used stack-allocated buffers. Because sprintf()
`does not check for buffer overflows, an attacker could overwrite the execution stack, thereby transferring
`control to arbitrary code. Attackers have exploited the same bug in the Unix syslog() library routine
`(via sendmail) to take over machines from across the network[8]. In later Java releases, all of these calls
`were fixed in the Java runtime. However, the bytecode disassembler was overlooked all the way through
`the JDK 1.0 release. Users disassembling Java bytecode using javap were at risk of having their machines
`compromised if the bytecode had very long method names. This bug was fixed in JDK 1.0.2.
`
`8Netscape solved the problem by storing the results of all DNS name lookups internally, forcing a given hostname to map to exactly
`one IP address. Netscape Navigator also stores the applet source as a function of its IP address, not hostname. This solution has the
`added property that it prevents time-varying DNS attacks. Previously, an attacker’s name server could have returned different IP
`addresses for the same hostname each time it was queried, allowing the same attacks detailed above.
`
`7
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 7
`
`

`
`3.5.3 Disclosing Storage Layout
`
`Although the Java language does not allow direct access to memory through pointers, the Java library
`allows an applet to learn where in memory its objects are stored. All Java objects have a hashCode()
`method which, unless overridden by the programmer, casts the address of the object’s internal storage to
`an integer and returns it. While this does not directly lead to a security breach, it exposes more internal
`state than necessary.
`
`3.5.4 Public Proxy Variables
`
`An interesting attack on HotJava-Alpha is that an attacker can change the browser’s HTTP and FTP proxy
`servers. An attacker can establish their own proxy server as a man-in-the-middle. As long as the client is
`using unencrypted HTTP and FTP protocols, we can both watch and edit all traffic to and from the HotJava-
`Alpha browser. All this is possible simply because the browser state was stored in public variables in public
`classes. While this attack compromises the user’s privacy, its implementation is trivial (see figure 3). By
`using the property manager’s put() method, an attackers stores a desired proxy in the property manager’s
`database. If the attacker can then entice the user to print a web page, these settings will be saved to disk,
`and will be the default settings the next time the user starts HotJava. If the variables and classes were
`private, this attack would fail. Likewise, if the browser were running behind a firewall and relied on proxy
`servers to access the web, this attack would also fail.
`We note that the same variables are public in JDK, although they are not used. This code is not part of
`Navigator or Internet Explorer.
`
`3.6 Inter-Applet Security
`
`Since applets can persist after the web browser leaves the page which contains them, it becomes important
`to protect applets from each other. Otherwise, an attacker’s applet could deliberately sabotage a third-
`party’s applet. More formally, the Java runtime should maintain non-interference[18, 19] between unrelated
`applets. In many environments, it would be unacceptable for an applet to even learn of the existence of
`another applet.
`In Netscape Navigator, AppletContext.getApplets() is careful to only return handles to applets
`on the same web page as the caller. However, an applet could easily get a handle to the top-level ThreadGroup
`and then enumerate every thread running in the system, including threads belonging to other arbitrary ap-
`plets. The Java runtime encodes the applet’s class name in its thread name, so a rogue applet can now
`In addition, an applet could call the stop() or
`learn the names of all applets running in the system.
`setPriority() methods on threads in other applets. The SecurityManager only checked that applets
`could not alter the state of system threads; there were no restraints on applets altering other applet threads.
`Netscape Navigator 4.0 prevents an attacker from seeing threads belonging to applets on other web pages,
`in the same way it protects applets. Internet Explorer allows an applet to see those threads, but calls to
`stop() or setPriority() have no effect.
`An insidious form of this attack involves a malicious applet that lies dormant except when a particular
`victim applet is resident. When the victim applet is running, the malicious applet randomly mixes degrada-
`tion of service attacks with attacks on the victim applet’s threads. The result is that the user sees the victim
`applet as slow and buggy.
`
`3.7 Java Language Implementation Failures
`
`Unfortunately, the Java language and the bytecode it compiles to are not as secure as they could be. There
`are significant differences between the semantics of the Java language and the semantics of the bytecode.
`First, we discuss David Hopwood’s attack[24] based on package names. Next, we present our attack that
`runs arbitrary machine code after compromising the type system. Several flaws in the type system are
`examined, including two first noted by Tom Cargill.
`
`8
`
`BLUE COAT SYSTEMS - Exhibit 1039 Page 8
`
`

`
`3.7.1 Illegal Package Names
`Java packages are normally named java.io, java.net, etc. The language prohibits “.” from being the
`first character in a package name. The runtime system replaces each “.” with a “/” to map the package
`hierarchy onto the file system hierarchy; the compiled code is stored with the periods replaced with slashes.
`David Hopwood found that if the first character of a package name was “/”, the Java runtime system would
`attempt to load code from an absolute path[24], since absolute pathnames begin with a “/” character on
`Unix or Windows. Thus, if an attacker could place compiled Java in any file on the victim’s system (either
`through a shared file system, via an incoming FTP directory, or via a distributed file system such as AFS),
`the attacker’s code would be treated as trusted, since it came from the local file system rather than from
`the network. Trusted code is permitted to load dynamic link libraries (DLLs, written in C) which can then
`ignore the Java runtime and directly access the operating system with the full privileges of the user.
`This attack is actually more dangerous than Hopwood first realized. Since Netscape Navigator caches
`the data it reads in the local file system, Netscape Navigator’s cache can also be used as a way to get a
`file into the local file system. In this scenario, a normal Java applet would read (as data) files containing
`bytecode and DLL code from the server where the applet originated. The Java runtime would ask Navigator
`to retrieve the files; Navigator would deposit them in the local cache. As long as the applet can figure out
`the file names used by Navigator in its cache, it can execute arbitrary machine code without even needing
`prior access to the victim’s file system.
`
`3.7.2 Superclass Constructors
`
`The Java language[21] requires that all constructors call either another constructor of the same class, or a
`superclass constructor as their first action. The