`
`1996 IEEE Symposium on Security and Privacy, Proceedings
`Meeting Date : 06 May 1996-08 May 1996
`
`Java Security: From HotJava to Netscape and Beyond
`
`Drew Dean
`ddean @cs.princeton.edu
`
`Edward W,Felten
`felten @cs.princeton.edu
`Department of Computer Science
`Princeton University
`Princeton, NJ 08544
`
`Dan S, Wallach
`dwallach @cs.princeton.edu
`
`Abstract
`
`The introduction ofJava applets hus taken the World Wide
`Web by storm, Information servers van customize the pre-
`sentation of their content with server-supplied code which
`executes inside the Web browser. We examinethe Java lan-
`guage and both the HotJava and Netscape browsers which
`support it, and find a significant number of flaws which
`compromise their security, These %aws arise for several
`reasons, including implementation errors, unintended inter-
`actions between browserfeatures, differences between the
`Java language and bytecode semantics, and weaknesses in
`the design of the language and the Zytecodeformat. On a
`deeperlevel, theseflaws arise because ofweaknessesin the
`design methodology used in creating Java andthe 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.
`Manycontent providers have expressed frustration with the
`inability to express their ideas in HTML. For example, be-
`fore 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 popu-
`Jarized the notion of downloading a program (called an ap-
`plet) which runsinside the Web browser. Such remote code
`raises serious security issues; a casual Web reader should
`not be concerned about malicious side-effects from visit-
`ing a Web page. Languages such as Java[9], Safe-Tcl[3],
`Phantom(8], and Telescript{10] have been proposed for run-
`
`ning downloaded code, and each has varying ideas of how
`-to thwart malicious programs,
`After several years of developmentinside Sun Microsys-
`tems,the Java language was released in mid-1995aspart of
`Sun’s HotJava Web browser. Shortly thereafter, Netscape
`Communications Corp. announced they had licensed Java
`and would incorporate it into version 2.0 of their market-
`leading Netscape Navigator Web browser. With the support
`ofat least two influential companies behindit, Java appears
`to have the best chance of becoming the standard for exe-
`cutable content on the Web. This also makes it an attractive
`target for malicious attackers, and demands external review
`of its security.
`Netscape and HotJava! are examples of two distinct ar-
`chitectures for building Web browsers. Netscape is written
`in an unsafe language, and runs Java applets as an add-on fea-
`ture. HotJava is written in Javaitself, with the same runtime
`system supporting both the browser and the applets. Both ar-
`chitectures have advantages and disadvantages with respect
`to security: Netscape can suffer from being implemented in
`an unsafe language (buifer overflow, memory leakage,etc.),
`but provides a well-defined interface to Java. In Netscape,
`Java applets can name only those functions and variables
`explicitly exported to the Java subsystem, HotJava, imple-
`mented in a safe language, does not suffer from potential
`memory corruption problems, but can accidentally export
`too muchof its environmentto applets.
`In order to be secure, such systems mustlimit applets’
`access to system resources such asthefile system, the CPU,
`the network, the graphics display, and the browser’s internal
`state. The language’s type system should be safe — prevent-
`ing forged pointers and checking array bounds. Addition-
`ally, the system should garbage-collect memory to prevent
`memory leakage, and carefully manage system calls that
`can access the environment outside the program,as well as
`
`‘Unless otherwise noted, “HotJava”refers to the 1.0 alpha 3 release of
`the HotJava Web browser fram Sun Microsystems, “Netscape” refers to
`Netscape Navigator 2.0, and “JDK”refers to the Java Development Kit,
`version 1.0, from Sun.
`‘
`
`0-8186-7417-2/96 $5.00 © 1996 IEEE
`
`CS-1024
`Cisco Systems, Inc. v. Finjan, Inc.
`
`CS-1024
`Cisco Systems, Inc. v. Finjan, Inc.
`
`

`

`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 tagged with the ClassLoader that loaded it. The
`SecurityManager has methods to determineif a class
`loaded by a ClassLoaderis in the dynamic call chain,
`and if so, where. This nesting depth is then used to make
`access control decisions.
`Java programmers can combine related classes into a
`package. These packages are similar to name spaces in
`C++[32], modules in Modula-2[33], or structures in Stan-
`dard ML[25]. While package names consist ofcomponents
`separated by dots, the package name space is actually flat:
`scoping rules are not related to the apparent name hierar-
`chy. A (package, source of code) pair-defines the scope of
`a Java class, method, or instance variable thatis not given
`apublic, private, or protected modifier, In Java,
`public and private have the same meaning as in C++:
`Public classes, methods, and instance variables are acces-
`sible everywhere, while private.methods andinstance vari-
`ables are only accessible inside the class definition. Java
`protected methods and variables are accessible in the
`class or its subclasses or in the current (package, source
`of code) pair; private protected methods andvari-
`ables are only accessible in the class or its subclasses,like
`C++’s protected members. 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 {
`private protected int i;
`void SetFoo(Foo 0)
`{ 0.i = 1;
`woid SetBar(Bar o)
`{ o.i = 1;
`
`} // Legal
`} // Legal
`
`} c
`
`}
`
`lass Bar extends Foo {(
`void SetFoo(Foo 0)
`{ o.i = 1;
`void SetBar(Bar 0)
`{ 0.i = 1;
`
`}) // Illegal
`} // Legal
`
`The definition of protected was different in some
`early versions of Java; it was changed duringthe beta-test
`period to patch a security problem.
`The Java bytecode runtime system is designed to enforce
`the language's access semantics. Unlike C++, programsare
`not permitted to forge a pointerto a function andinvokeit di-
`rectly, nor to forge a pointer to data and accessit directly, If
`a rogue applet attemptsto 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 assures application code cannot break these specifi-
`cations.
`The Java documentation claims that the safety of Java
`bytecodes can bestatically determined at load time. Thisis
`not entirely true: the type system uses a covariant[5] rule
`for subtyping arrays, so array stores require run time type
`
`
`
`allow applets to affect each other,
`The Anderson report[2] describes an early attempt to
`build a secure subset of Fortran. Tais effort was a failure
`because the implementors failed to considerall of the con-
`sequencesof the implementation ofone construct: assigned
`GOTO.This subtle flaw resulted in a complete break of the
`system.
`The remainderofthis paperis structured as follows, Sec-
`tion 2 discusses the Java language in more detail, section 3
`gives a taxonomyof knownsecurity flaws in HotJava and
`Netscape, section 4 considers how the structure of these
`systems contributes to the existence of bugs, section 5 dis-
`cusses the need for flexible security in Java, and section 6
`concludes.
`
`2. Java Semantics
`
`Java is similar in many ways to C++[31]. Both pro-
`vide support for object-oriented programming, share many
`keywords and other syntactic elements, and can be used to
`develop standalone applications, Java diverges from C++
`inthe following ways: it is type-sa*e, supports only single
`inheritance (although it decouples subtyping from inheri-
`tance), and has language support for concurrency.
`Java
`supplies each class and object witli a lock, and provides
`the synchronized keyword so each class (or instance
`
`monitor[21].
`
`of a class, as appropriate) can operate as ‘Mesa-style
`Java compilers produce a machine-independent byte-
`code, 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 distin-
`guishes remote code from local cod«, Separates urces” of
`Java bytecodeare loaded in separatenaming environments to
`prevent both accidental and malicious name clashes. Byte-
`code loaded from thelocalfile system is visible to all applets.
`The documentation[15] says the “svstem name space” has
`two special properties:
`
`1, It is shared byall “namespaces.”
`
`2. Itis always searchedfirst, to preventdownloadedcode
`from overriding a system class.
`
`However, we have foundthat the second property does not
`hold.
`The Java runtime system knows how to load byte-
`code only from the localfile system. To load code from
`other sources,
`the Java runtime system calls a subclass
`of the abstract class ClassLoader, which defines an
`interface for the runtime system to ask a Java program
`2While the documentation{15] does not define “source”, it appears to
`mean the machine and Web page oforigin. Sun has announced| plans to
`include support for digital signatures in a future version.
`
`191
`
`

`

`checks? in addition to the normal array bounds checks. Un-
`fortunately, this means the bytecode verifier is not the only
`piece of the runtime system that must be correct to ensure
`security. Dynamic checks also introduce a performance
`penalty.
`
`2.1. Java Security Mechanisms
`
`In HotJava, 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[20]. The SecurityManager
`defines and implements a security policy, centralizing all ac-
`cess control decisions. Netscapealso uses this architecture,
`When the Java runtime system starts up, there is no se-
`curity managerinstalled. Before executing untrusted 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 SecurityExceptionforall access checks, forcing
`the user agent to define and implement its own policy in a
`subclass of SecurityManager. The security managers
`in both JDK and Netscape typically use the contents of the
`call stack to decide whether or not to grant access,
`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 ofseparate address spacesfor protection,Java is em-
`beddable in other software, and performsbetter because pro-
`tection boundaries can be crossed without a context switch.
`
`3. Taxonomyof Java Bugs
`
`We now present a taxonomy of Java bugs, past and
`present. Dividing the bugs into classes is useful because
`it helps us understand how and whythey arose,andit alerts
`us to aspects of the system that may harborfuture bugs.
`
`3.1, Denial of Service Attacks
`
`Java has few provisions to thwart denial of service at-
`tacks. The obvious attacks are busy-waiting to consume
`CPUcyclesand allocating memory until the system runsout,
`
`?For 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[ J; similarly, y
`could really have type A. The body of pracis 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 8. This condition cannot be checked statically,
`
`starving other threads and system processes. Additionally,
`an appletcan acquire locksoncritical pieces of the browser
`to cripple it. For example, the code in figure 1 locks the
`status line at the bottom of the HotJava browser, effectively
`preventing it from loading any more pages. In Netscape,
`this attack can lock the java.net. InetAddress class,
`blocking all hostname lookups and hence all new network
`connections. Both HotJava and Netscape have several other
`classes suitable for this attack. The attack could be pre-
`-vented by replacing suchcritical classes with wrappers that
`do not expose the locks to outsiders. However, the CPU
`and memory attacks cannot beeasily fixed; many genuine
`applications may need Jarge amounts of memory and CPU,
`There are two twists that can make denial of service
`attacks moredifficult to cope with. First, an attack can be
`programmed to occur after some time delay, causing the
`failure to occur whenthe user is viewing a different Web
`page, thereby maskingthe sourceof the attack. Second, an
`attack can cause degradation ofservice rather than outright
`denial of service. Degradation of service meanssignificantly
`reducing the performance of the browser without stopping
`it. For example, the locking-based attack could be used to
`hold a critical system lock mostofthe time,releasing it only
`briefly and occasionally. The result would be a browser that
`runs very slowly.
`Sun has said that they consider denialof service attacks
`to be low-priority problems[14].
`
`3.2. Two ys. Three Party Attacks
`
`It is useful to distinguish between twodifferent kinds of
`attack, which weshall cqll two-party and three-party, A two-
`party attack requires that the Webserver the applet resides on
`participate in the attack. A three-party attack can originate
`from anywhere on the Internet, and might spreadif 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
`
`in both HotJava and
`Various covert channels exist
`Netscape, allowing applets to have two-way communica-
`tion with arbitrary third parties on the Internet.
`Typically, most HotJava users will use the default net-
`work security mode, which only allows an applet to connect
`to the host from which it was loaded. This is the only se-
`curity mode available to Netscape users.
`In fact, HotJava
`and Netscapefail to enforce this policy through a number of
`errors in their implementation.
`The accept () system call, used to receive a network
`connection initiated on anotherhost, is not protected by the
`
`192
`
`

`

`
`
`synchronized (Class.forName("net.www.html.MeteredStream"))
`while(true) Thread.sleep(10000);
`
`{
`
`}
`
`Figure 1. Java code fragment to deadlock the HotJava browserby lockingits status line.
`
`
`
`Figure 2, A Three Party Attack — Charlie pro-
`duces a Trojan horse applet. Boblikes 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 Bobis necessary.
`
`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 wenotified Sun about these channels, they said
`the DNS channel would be fixed[26], but in fact it was still
`available in JDK and Netscape. Netscape has since issued a
`patch to fix this problem.
`Asfar as we know, nobody has donean analyis of storage
`or timing channels in Java.
`
`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 environmentto send over the channel.
`In HotJava, 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 controllists (ACLs)* spec-
`ify where reading and writing of files or directories may
`usual security checks in HotJava. This allows an arbitrary
`occur without the user’s explicit permission, By default, the
`host on the Internet to connect to a HotJava browser as
`write ACL is empty and the read ACL contains the HotJava
`long as the location of the browser is known. For this to
`library directory and specific MIME mailcapfiles. The
`be a useful attack, the applet needs to signal the external
`read ACLalso containsthe user’s public_html]directory,
`agent to connect to a specified port. Even an extremely
`which may contain information which compromisesthepri-
`low-bandwidth covert channel would besufficient to com-
`vacy of the user. The Windows 95 version additionally al-
`municate this information. The accept() call is properly
`lows writing (but not reading) in the \TEMP directory. This
`protected in Netscape, but the attack describedin section 3.7
`allows an applet to corrupt files in use by other Windows
`allows applets to call accept ().
`applicationsif the applet knows or can guess namesthefiles
`If the Web server which served the applet is running
`may have. At a minimum, an applet can consumeall the
`an SMTP mail daemon, the applet can connect to it and
`free spacein the file system. These security concerns could
`transmit an e-mail message to any machineon the Internet.
`be addressed by the user editing the ACLs; however, the
`Additionally, the Domain Name System (DNS)can be used
`system default should have beenless permissive. Netscape
`as a two-way communication chan.i¢l to an arbitrary host
`does not permit any file system access by applets.
`on the Internet. An applet may refcrenceafictitious name
`In HotJava, we could learn the user’s login name, machine
`in the attacker’s domain. This transmits the name to the
`name, 3S well as the contents of all environment variables;
`attacker’s DNSserver, which could interpret the nameas a
`System.getenv() in HotJava has no security checks,
`message, and then sendalist of arbitrary 32-bit IP numbers
`Byprobing environmentvariables,including the PATH vari-
`as a reply. Repeated DNS calls by the applet establish a
`able, we can often discover what software is installed on the
`channel between the applet and the attacker’s DNSserver.
`user’s machine, This information could be valuable either
`This channel also passes through a number of firewalls[7].
`to corporate marketing departments, or to attackers desir-
`In HotJava, the DNS channe] was available even with the
`ing to break into a user’s machine, In JDK and Netscape,
`security mode set to “no network access,” although this
`System.getenv() was replaced with “system proper-
`was fixed in JDK and Netscape. DNS has other security
`ties,” many of which are not supposed to be accessible by
`implications; see section 3.5 for det: ils.
`Another third-party channel is available with the URL
`redirect feature. Normally, an applet may instruct the
`
`4While Sun calls these “ACLs”, they actually implementprofiles — a
`list offiles and directories granted specific access permissions.
`
`193
`
`

`

`
`
`applets. However, the attack described in section 3.7 allows
`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 informa-
`tion. Timing information is also needed for the exploitation
`of covert timing channels. ‘Fuzzy time”[18] should be in-
`vestigated to see if it can be used to mitigate both of these
`problems.
`
`3.5. Implementation Errors
`
`Somebugsarise fromfairly localized errors in the im-
`plementation of the browser or the Java subsystem.
`
`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 HTTP
`retrievals. FTP retrievals may be redirected
`with similar code.
`
`1, Getall the IP-addresses of the hostname that the applet
`came from,
`
`2. Getall the IP-addressesof the hostnamethat the applet
`is attempting to connectto.
`
`3. If any address in the first set matches any address in
`the second set, allow the connection. Otherwise, do
`not allow the connection.
`
`Asof this writing, Sun and Netscape have both issued
`patchesto fix this problem. However, the attack described
`DNS WeaknessesAsignificant problem appears in the
`in section 3,7 reopensthis hole.
`JDK and Netscape 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 sound (although
`Buffer Overflows HotJava and the alpha release of JDK
`inconvenient at times), it was not uniformly enforced, This
`had many unchecked sprintf () calls that used stack-
`policy was enforced as follows:
`allocated buffers. Because sprint£() does not check for
`buffer overflows, an attacker could overwrite the execution
`stack, thereby transferring controlto arbitrary code. Attack-
`ers have exploited the same bug in the Unix syslog ()
`library routine (via sendmail) to take over machines from
`across the network[6]. In Netscape and the beta release of
`JDK,all of these calls were fixed in the Java runtime, How-
`ever, the disassembler was overlookedall the way through
`the JDK 1.0 release, Users disassembling Javabytecode us-
`ing javapareat risk of having their machines compromised
`if the bytecode has very long method names.
`
`The problem occurs in the second step: the applet can ask
`to connect to any hostnameonthe Internet, so it can control
`which DNSserver supplies the second list of IP-addresses;
`information from this untrusted DNSserveris used to make
`an access contro! decision. There is nothing to prevent an
`attacker from creating a DNS server that lies.
`In particu-
`lar, it may claim that any name for whichit 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 can connect to any
`desired machineon the Internet. The applet can even encode
`the desired IP-address pair into the hostnamethat it looks
`up, This attack is particularly dangerous when the browser
`is running behind a firewall, because-the malicious applet
`can attack any machine behindthe firewall. At this point, a
`rogue applet can exploit a whole legion of known network
`security problemsto break into other nearby machines.
`This problem was postulated independently by Steve
`Gibbons{11] and by us, To demonstrate this flaw, we pro-
`duced an applet that exploits an old sendmail hole to run
`arbitrary Unix commands as user daemon.
`
`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 objectsare stored. All Java objects have ahashCode()
`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 internalstate than necessary.
`
`Public Proxy Variables Perhaps the strongest attack we
`found on HotJava is that we can change the browser’s HTTP
`and FTP proxy servers. We can establish our own proxy
`server as a man-in-the-middle. As long asthe clientis using
`unencrypted HTTP and FTP protocols, we can both watch
`andeditall traffic to and from the HotJava browser. Allthis
`is possible simply because the browser state was stored in
`public variables in public classes. While this attack com-
`promises the user’s privacy,
`its implementationis trivial
`(see figure 3), By using the property manager’s put ()
`
`194
`
`

`

`
`
`
`
`victim.org
`
`hostname
`lookup
`
`
`
`attacker.com
`
`hostname lookup
`
`
`
`
`applet exploits
`sendmailbug
` information leak
`
`
`
`
`Figure 4. DNS subversion of Java: an applet travels from attacker.com to victim.org through normal
`channels. The applet then asks to connectto foo.attacker.com, which is resolved by attacker.com’s
`DNSserverto be victim.org’s internal mail server which can then be attacked.
`
`method, we store our desired proxy in the property man-
`An insidious form of this attack involves a malicious ap-
`plet that lies dormant except whenaparticular target applet
`ager’s database. If we can then entice the user to print a
`Webpage,these settings will be saved to disk, and will be
`is resident. When the target applet is running, the malicious
`applet randomly mixes degradation of service attacks with
`the default settings the next time the. user starts HotJava. If
`the variables and classes were private,this attack would fail.
`attacks on the target applet’s threads. The result is that the
`Likewise,if the browser were running behinda firewall and
`user sees the target applet as slow and buggy.
`relied on proxy servers to access the Web,this attack would
`also fail.
`We note that the same variables are public in JDK, al-
`though they are not used, This code-is not part of Netscape.
`
`3.7. Java Language and Bytecode Differences
`
`3.6. Inter-Applet Security
`
`Since applets can persist after the Web browser leaves
`the page which contains them,it becomes importantto sep-
`arate 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[12, 13] between applets.
`In many environ-
`ments, it would be unacceptable for an applet to even learn
`ofthe existence of anotherapplet.
`In Netscape, AppletContext.getApplets{) is
`careful to only return handles to appiets on the same Web
`page as the caller. However, an applet may easily get a
`handle to the top-level ThreadGroup‘and then enumer-
`ate every thread running in the sysiem, including threads
`belonging to other arbitrary applets. The Java runtime en-
`codesthe applet’s class namein its thread name, so a rogue
`applet can now learn the names of all applets running in
`the system.
`In addition, an applet can call the stop ()
`or setPriority() methods on threadsin other applets.
`The SecurityManager only cheuks that applets cannot
`alter system threads; there are no restraints on applets alter-
`ing other applet threads,
`
`Unfortunately, theJava language and the bytecode itcom-
`piles to are not as secure as they could be. Thereare sig-
`nificant differences between the semantics of the Java lan-
`guage and the semantics of the bytecode. We discuss super-
`class constructors and David Hopwood’s attack[17] based
`on package names as examples of language versus bytecode
`differences. We then discuss related security weaknesses.
`
`Superclass Constructors The Java language[9] requires
`that all constructors call either another constructor of
`the same class, or a superclass constructor as their
`first action,
`The system classes ClassLoader,
`SecurityManager, and FileInputStrean allrely
`on this behavior for their security, These classes have
`constructors that check if they are called from an applet,
`and throw a SecurityExceptionif so. Unfortunately,
`while the Java language prohibits the following code, the
`bytecodeverifier readily accepts its bytecode equivalent:
`class CL extends ClassLoader {
`cL) {
`}
`try { super();
`catch (Exception e)
`
`{}
`
` unini-
`(partially
`build
`to
`us
`allows
`This
`tialized) ClassLoaders, SecurityManagers, and
`
`195
`
`

`

`FileInputStreams, ClassLoaders are the most in-
`teresting class to instantiate, as any code loaded by a
`ClassLoader asksits ClassLoaderto load any classes
`it needs, This is contrary to the documentation[15] that
`claims the system name space is always searched first;
`we have verified this difference experimentally.
` For-
`tunately from the attacker’s viewpoint, ClassLoaders
`don’t have any instance variables, and the actual code in
`ClassLoader’s constructor only needs to run once —
`and it always runs before the first applet is loaded, The
`result of this attack,
`therefore,
`is a properly initialized
`ClassLoader which is under the control of an applet.
`Since ClassLoadersdefine the name space seen by other
`Java classes, the applet can construct a completely cus-
`tomized name space.
`a
`creating
`that
`discovered
`We
`have
`recently
`ClassLoadergivesanattackerthe ability to defeat Java’s
`type system. Assumethat classes A and B both refer to a
`class named C, A ClassLoader could resolve A against
`class C, and B against class C’. If an object of class C
`is allocated in A, and then is passed as an argument to a
`method of B, the method in B will treat the object as hav-
`ing a different type, C’. If the fields of C’ have different
`types ordifferent access modifiers (public, private,
`protected)than those of C, then Java’s type safety is
`defeated, This allows an attacker to get and set the value of
`any non-static variable, and call any method (including
`native methods). This attack also allows an applet to mod-
`ify the class hierarchy,as it can set variables normally only
`writable by the runtime system, Java's bytecode verification
`and class resolution mechanisms are unable to detect these
`inconsistencies because Java defines only a weak correspon-
`dence between class names and Class objects.
`We discovered this attack just before the submission
`deadline for this paper. We have implemented all of the
`type-system violations described above, but have not had
`time to investigate the full ramifications of this attack.
`
`Java packages are normally
`Illegal Package Names
`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 pack-
`age hierarchy onto the file system hierarchy; the compiled
`codeis stored with the periods replaced with slashes. David
`Hopwoodfound thatif the first character of a package name
`was ‘/’, the Java runtime system would attempt to load code
`from an absolute path[{17], since absolute pathnames begin
`with a ‘/ character. Thus, if an attacker could place com-
`piled 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 fromthelocalfile
`system rather than from the network. Trusted code is per-
`
`mitted to load dynamiclink 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 caches the data it reads in the
`local file system, Netscape’s cache can also be used as a
`way to geta file into the localfile 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 Netscape to retrieve
`the files; Netscape would deposit them in the local cache,
`As long as the applet canfigure outthe file names used by
`Netscapein its cache,it can execute arbitrary machine code
`without even needing prior accessto the victim’s file system.
`
`3.8. Java Language and Bytecode Weaknesses
`
`Webelieve the the Java language and bytecodedefinitions
`are weaker than they should be from a security viewpoint.
`The language has neither a formal semantics nor a formal
`description ofits type system, The module system is weak,
`the scopingrulesare too liberal, and methods may be called
`on partially initialized objects[16]. The bytecode is in lin-
`ear form rather than a tree representation, it has no formal
`semantics, it has unnaturally typed constructors, and it does
`not enforce the private modifier on code loaded from
`the localfile system. The separation of object creation and
`initialization poses problems. Webelieve the system could
`be stronger if it were designed differently.
`
`Language Weaknesses The Java language has neither a
`formal semanticsnora formal description ofits type system.
`We do not know what a Java program means, in any formal
`sense, so we cannotformally reason about Java and the secu-
`tity properties ofthe Javalibraries written in Java. Java lacks
`a formaldescription ofits type system, yetthe security of
`Java relies on the soundness ofits type system. Java’s pack-
`age system provides only basic modules, and these modules
`cannotbe nested,although the namespace superficially ap-
`pears to be hierarchical. With properly nested modules,
`a programmercouldlimit the visibility of security-critical
`components. In the present Java system,only accessto vari-
`ablesis con