`
`1996 IEEE Symposium on Security and Privacy, Proceedings
`Meeting Date 1 06 May 1996—08 May 1996
`
`Java Security: From HotJava to Netscape and Beyond
`
`Drew Dean
`ddcan@cs.prinoeton.edu
`
`Edward W. Fcltcn
`feltcn@cs.princeton.edu
`
`Dan S. Wallach
`dwaflach©cs.princeton.edu
`
`Dcp artmcnt of Computer Science
`Princeton University
`Princeton, NJ 08544
`
`Abstract
`
`The introduction ofJava applets has taken the World ‘Wide
`Web by storm. Infomtatton servers can. customize the pre~
`sentation of their content with server-supplied code which
`executes inside the Web browser We examine the Java ion-
`
`guoge and both the Hottava and Netscape browsers which
`support it, and find a significant number offlaws which
`compromise their security. These flaws arise for several
`reasons, including implementation errors, unintended inter—
`actions between browser features, rlifl‘erences between the
`Java ionguage and bytecode semantics, and weaknesses in
`the design of the language and the .i‘ytecode format. On a
`deeper level, theseflaws arise because of weaknesses in the
`design methodology used in creating Java and the broWsei-s.
`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. be.-
`fore support for tables was common, many pages simply
`usod 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-
`larized the notion of downloading a program (called an ap-
`plet) which runs inside the Web browser. Such remote code
`raises serious security issues; a casual Web reader should
`not be concerned about malicious sidoeffccuz from visit-
`
`ing a Web page. Languages such on Javalg], Safe-Tcl[3],
`Phantom[8], and TclcScrith 0] have been proposed for rum
`
`ning downloaded code, and each has varying ideas of how
`-lo thwart malicious programs.
`After several years of development inside Sun Microsys-
`toms, the Java language was released in mid-1995 as part of
`Sun‘s HorJava Web browser. Shortly thereafter, Netscape
`Communications Corp. announced they had licensed Java
`and would incorporate it into version 2.0 of their market-
`lcading Netscape Navigator Web browser. With the support
`of at least two influential companies behind it, 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 Hotlaval are. examples of two distinct ar—
`chitccturcs for building Web browsers. Netscape is written
`in an unsafe language, and runs Java applets as an add—on fea-
`ture. HotIava is written in Java itself. with the same runtimc
`system supporti In; 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 (butler 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. Hotlava. implo-
`mcntcd in a safe language, does not suffer from potential
`memory corruption pmblcms, but can accidentally export
`too much of its cnvircnmcntto applets.
`In order to be secure, such systems must limit applets’
`access to system resources such as the filo system, the CPU,
`the network, the graphics display, and the browser’s internal
`state. The langucgo'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
`
`1Unlcse otherwise noted, “Hotlavn” refers to the 1.0 alpha 3 release of
`the llotlava Web browser from Sun Microoystems, "Netscape" refers to
`Netscape Navigator 2.0, and “JDK” refers to the Java Development Kit.
`version 1.0, from Sun.
`'
`
`{1—8186-741'F-2l96 $5.00 © 1996 IEEE
`
`190
`
`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 Classnoeder.
`Each class
`is tagged with the ClassLoader that loaded it. The
`Securityl-Iartager 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.
`Java programmers can combine related classes into a
`package. These packages are similar to name spaces in
`C++[32], modules in Module-2&3], or structures in Stan-
`dard ML[25]. While package names consist of components
`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 that is not given
`a public, 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 and instance vari-
`ables are only accessible inside the claSs definition.
`lava
`protected methods and variables are accessible in the
`class or its subclasses or in the current (package, source
`of code) pair; private protected methods and vari-
`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 SetFootFoo o)
`{ o.i =
`void SetBar(Bar o)
`{ o.i = 1:
`
`l H Legal
`} If Legal
`
`} c
`
`}
`
`.
`lass Ber extends Foo {
`void SetFoo(Fco o}
`{ o.i
`void SetBartBar o}
`{ o.i
`
`-
`-
`
`l {I Illegal
`} fl Legal
`
`llIl p
`
`The definition of protected was different in some
`early versions of lava; it was changed during the beta—test
`period to patch a security problem.
`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 di~
`rectly, 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 assures application code cannot break these specifi-
`cations.
`
`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{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 Portrait. This effort was a failure
`because the implementors failed to consider all of the con-
`sequences of the implementation of one ccnithuct: assigned
`GOTO. This subtle flaw resulted in a complete break of the
`system.
`The remainder of this paper is structured as follows. Sec—
`tion 2 discusses the Java language in more detail, section 3
`gives a taxonomy of known security 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++
`in. the following ways: it is type-sate, supports only single
`inheritance (although it decouples subtyping'llfrom inheri~
`tance), 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 at Mesa-style
`monitoriZl].
`1
`Java compilers produce a machine-indepehdent byte»
`code, which may be transmitted across a network and then
`interpreted or compiled to native code by the hiya runtirne
`system.
`In support of this downloaded code, Java distin-
`guishes remote code from local code. Separate hourcesz of
`Java bytecode are loaded in separate'nami ng environments to
`prevent both accidental and malicious name clashes. Byte-
`code loaded from the local file system is visible to 'all applets.
`The documentation[15] says the “system name space” has
`tWo special properties:
`
`1. It is shared by all “name spaces."
`
`2. It is always searchedfirst, to preventdownloadedcode
`from overriding a system class.
`
`However. we have found that the second property does not
`hold.
`
`The Java runtime system knows how to load byte-
`code only from the local file system. To load code from
`other sources,
`the Java runtime system calls a subclass
`of the abstract class ClassLoac‘er, which defines an
`
`interface for the runtime system to ask a Java program
`3‘ch the documentationilfi] does not define "source", it appears to
`mean the machine and Web page of origin. Sun has atmounced'plans to
`include support for digital signatures in a future version.
`
`191
`
`

`

`checks3 in addition to the normal array bounds checks. Un~
`fortunately, this means the bytecodc 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 Hotlava. 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. Netscape also uses this architecture.
`When the Java runtime system starts up. there is no se-
`curity manager installed. Before executing untrusted code.
`it is the Web browser’s or other user agent‘s responsibility
`to install a security manager. The Securityl-Ianager
`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 Securityldanager. The security managers
`in both IDK 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 lamperproof. By using types,
`instead of separate address spaces for protection, Java is em-
`bedd able in other software. and performs better because pro-
`tection boundaries can be crossed without a context switch.
`
`3. Taxonomy of 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 why they arose, and it alerts
`us to aspects of the system that may harbor future bugs.
`
`starving other threads and system processes. Additionally,
`an applet can acquire locks on critical pieces of the browser
`to cripple it. For example. the code in figure 1 looks the
`status line at the bottom of the Hotlava browser, effectively
`preventing it from loading any more pages. In Netscape,
`this attack can lock the java . net: . InetAddress class,
`blocking all hostname hookups and hence all new network
`connections. Both Hotlava and Netscape have several other
`classes suitable for this attack. The attack could be prev
`vented by replacing such critical classes with wrappers that
`do not expose the locks to outsiders. However, the CPU
`and memory attacks cannot be easily fixed; many genuine
`applications may need large amounts of memory and CPU.
`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 ofservice 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.
`Sun has said that they consider denial of service attacks
`to be low-priority problemslld].
`
`3.2. No 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). Thee-party attacks are more dangerous than
`two—party attacks because they do not require the collusion
`of the Web server.
`
`3.1. Denial of Service Attacks
`
`3.3. Covert Channels
`
`Various covert channels exist
`
`in both HotJava and
`
`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 Netscape fail 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 protected by the
`
`Java has few provisions to thwart denial of service at-
`tacks. The obvious attacks are busvaaiting to consume
`CPU cycles and allocating memory until the system runs out,
`
`3For example. suppose that A is a subtype of B; then the lava typing
`rules say that n [} (“array of a") is a subtype of Bl ]. Now the following
`procedure cannot be statically typo—checked:
`void proc {BI} x, B y} {
`xtol = v:
`
`}S
`
`ince A [l is a subtype of B l l, x could really have type m];:ri|u1'larlyI 3;
`could really have type n.1‘he body otoroc is not type-safe if the value of
`it passed in by the caller has type All and the value of y passed in by the
`caller has type B. This condition cannot be checked statically.
`
`1.92
`
`

`

`
`
`synchronized {Clasa. forName { "net . ww.htm1 .Matorodstream" } l
`while {true} Thread. sleep { 10000] ,-
`
`{
`
`l
`
`Figure 1. Java code fragment to deadlock the HotJave browser by locking Its status line.
`
`
`
`Figure 2. A Three Party Attack — Charlie pro-
`duces 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.
`
`usual security checks in HotJava. This allows an arbitrary
`host on the Internet to connect to a Hotlava 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 com-
`
`municate this information. The accept t ) call is properly
`protected in Netscape. but the attack described in section 3.7
`allows applets to call accept [ ) .
`If the Web server which served 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 Daniela Nome Svstem (DNS) can be used
`as a twoiway communication charrit-l to an arbitrary host
`on the Internet. An applet may reftrence 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 firewallsfll.
`In HotJava, the DNS channel Was available even with the
`security mode set to “no network access,” although this
`was fixed in JDK and Netscape.
`IJNS has other security
`implications; see section 3.5 for det: its.
`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
`couldrecord theURLasamessage, then redirectthe browser
`to the original destination.
`When we notified Sun about these channels. they said
`the DNS channel would be fixcd[261, but in fact it was still
`available in IDK and Netscape. Netscape has since issued a
`patch to fix this problem.
`As far as we know, nobody has done an analyis of storage
`or timing channels in Java.
`
`3.4. Infomation 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 HotIava, 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)4 spec-
`ify where reading and writing of files or directories my
`Occur without the user’s explicit permission. By default. the
`write ACL is empty and the read ACL contains the HotIava
`library directory and specific MIME mailcep files. The
`read ACL also contains the user’s publ ic.htm1 directory,
`which may contain information which compromises the pri-
`vacy of the user. The Windows 95 version additionally al-
`lows writing (but not reading) in the \TEt-IP 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. Netscape
`does not permit any file system access by applets.
`In HotJava, we could learn the user’s login name, machine
`name. as wall as the contents of all environment variables;
`System.getenv{ )-
`in HotJava has no security checks.
`By probing environment variables. including the PATH vari-
`able. we can often discover what software is installed on the
`user’s machine. This information could be valuable either
`
`to Corporate marketing departments, or to attackers desir-
`ing to break into a user’s machine. In IDK and Netscape.
`System. getonvl ) was replaced with “system proper-
`
`ties," many of which are not. supposed to be accessible by
`
`“While Sun calls these "ACLs", they actually implement profiles —~ a
`list of tiles and directories granted spedfic access permissions.
`
`193
`
`

`

`
`
`applets. However, the attack described in section_3.'? 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-
`onabled Web browser may well run on prerelease hardware
`andlor software, an attacker could learn valuable informa-
`tion. Timing information is also needed for the exploitation
`of covert timing channels. “Fuzzy time"[lS] should be in-
`vestigated to see if it can be used to mitigate both of these
`problems.
`
`3.5. Implementation Errors
`
`Seine bugs arise from' fairly localized errors in the im-
`plementation of the browser or the Java subsystem.
`
`DNS Weaknesses A significant problem appears in the
`IDK and Netscape implementation of the policy that an
`applet can only open a TCPflP connection back to the server
`it was loaded from. While this policy is sound (although
`inconvenient at times), 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 occurs in the second swp: the applet can ask
`to connect to any hostnarne on the Internet. so it can control
`which DNS server supplies the second list of IP—addresses;
`information from this entrusted DNS server is used to make
`
`an access control 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 which it is responsible
`has any given set of addresses. Using the attacker’s DNS
`server to provide a pair of addresses (mchlne-to~conn est-t0,
`mohineapplet-mmefmm), the applet can connect to any
`desired machine on the Internet. The applet can 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-tho malicious applet
`can attack any machine behind the firewall. At this point, a
`rogue applet can exploit a whole legion of known netw0rk
`security problems to break into other nearby machines.
`This problem was postulated independently by Steve
`Gibbons[l 1] 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.
`
`hotjava.props.put("proxyHoet",
`
`_
`"proxy.attacker.com") ;
`" 8080 "l ;
`hotj ave .props .put { "proxyPort" ,
`hotj ava .props .put { "proxySet " , "true" i ,-
`l-lttpclienl:.cachingProxyHost =
`"proxy. attacker. corn";
`Httpclient.cachingProxyPort = 8080.-
`HttpClient .useProxyForCaching = true;
`
`Figure 3. Code to redirect all HotJava HTTP
`retrievals. FI'P retrievals may be redirected
`with similar code.
`
`As of this writing, Sun and Netscape have both issued
`patches to fix this problem. However. the attack described
`in section 3.7 reopens this hole.
`
`l-IotJava and the alpha release of JDK
`Buffer Overflows
`had many unchecked Sprintf ('1 calls that used stack-
`allocated buffers. Because sprint f t } does not check for
`buffer overflows, an attacker could overwrite the execution
`stack. thereby transferring control to arbitrary code. Attack-
`ers have exploited the same bug in the Unix sys log t }
`library routine (via sendmai 1) to take over machines from
`across the network[6]. In Netscape and the beta release of
`J'DK, all of these calls were fixed in the Java runtirne. How-
`ever. the disassembler was overlooked all the way through
`the JDK 1.0 release. Users disassembling Java'bytecode us-
`ing javap are at risk of having their machines compromised
`if the bytecode has very long method names.
`
`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 a hashCode { 1
`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.
`
`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
`serveras aman—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 browser. All this
`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 implementation is trivial
`(see figure 3). By using the property manager’s put (1
`
`194
`
`

`

`hosrname
`lockup
`
`hostname lockup
`
`
`
`
`
`victim.org
`
`
`
`atlacker.corn
`
`
`
`
`a
`latex lofts
`sghdmalfibug
` infannation leak
`
`
`
`
`Figure 4. DNS subversion ct Java: an applet travels from attackemom to vietltn.org through normal
`channels. The applet then asks to connect to too.attsclter.com, which is resolved by sttaeker.com’s
`DNS server to be vlctlm.org‘s Internal mall server which can then be attacked.
`
`method, we store our desired proxy in the property man-
`ager’s database. If we can then some 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 HolJava. 1f
`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. al-
`though they are not used. This code-is not part of Netscape.
`
`3.6. Inter-Applet Security
`
`Since applets can persist after the Web browser leaves
`the page which contains them, it becomes important to 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-
`interfercnce[l2, 13] between applets.
`In many environ-
`ments, it would be unacceptable for an applet to even learn
`of the existence of another applet.
`ln Netscape. AppletContexc . getApplets t) is
`careful to only return handles to apptets on the same Web
`page as the caller. However, an applet may easily get a
`handle to the top~1evel ThreadGroup and then enumer-
`ate every thread running in the system, including threads
`belonging to other arbitrary applets. The Java runtime en-
`codes the applet’s class name in 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 (l
`or setPriorityt ) methods on threads in other applets.
`The Securityfianager only checks that applets cannot
`alter system threads; there are no restraints on applets alter-
`ing other applet threads.
`
`An insidious form of this attack involves a malicious ap-
`plet that lies dormant except when a particular target applet
`is resident. When the target applet is running, the malicious
`applet randomly mixes degradation of service attacks with
`attacks on the target applet’s threads. The result is that the
`user sees the target applet as slow and buggy.
`
`3.7. Java Language and Bytecode Differences
`
`Unfortunately, the Java language and the by tecode it com-
`piles to are not as secure as they could be. There are 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 attackfl‘l] based
`on package names as examples of language versus bytecode
`differences. We then discuss related security weaknesses.
`
`Superclass Constructors The Java languagefQ] requires
`that all constructors call either another constructor of
`the same class. or a superclass constructor as their
`first action.
`The system classes ClassLoader.
`Securitytdaneger. and FileInputstream all rely
`on this behavior for their security. These classes have
`constructors that check if they are called from an applet,
`and throw a SecurityException if so. Unfortunately,
`while the Java language prohibits the following code, the
`bytesode verifier readily accepts its bytecode equivalent:
`class CL extends classLoeder {
`CLll
`(
`1
`try I supert):
`catch (Exception e) {i
`
`unini-
`(partially
`build
`to
`us
`allows
`This
`tialized) ClassLoaders, SecurityMansgsrs. and
`
`195
`
`

`

`FileInputStreams. ClassLoaders are the most in~
`teresfing class to instantiate, as any code loaded by a
`Ciao sLoader asks its ClassLoader to load any classes
`it needs. This is contrary to the documentationflfi] 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
`Classnoader’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 Clas sLoaders define 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
`Class sLoac‘ler gives an attacker the ability to defeat Java’s
`type system. Assume that classes A and B both refer to a
`class named C. A C lassboader 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 or different 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.
`
`lava packages are normally
`Illegal Package Names
`named java . io, java . not, etc. The language prohibits
`‘.’ from being the first character in a package name. The
`runtime system replaces each ‘.’ with a ‘l’ to map the pack-
`age 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 ‘I‘. the Java runn'rne system would attempt to load code
`from an absolute path[l7], since absolute pathnames begin
`with a ‘1!" character. Thus. if an attacker could place com-
`piled Iava 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 per—
`
`mitted 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 caches the data it reads in the
`local file system, Netscape’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 Netscape to retrieve
`the files; Netscape would deposit them in the local cache.
`As long as the applet can figure out the file names used by
`Netscape in its cache, it can execute arbitrary machine code
`without even needing prior access to the victim's file system.
`
`3.8. Java Language and Bytecodc Weaknesses
`
`We believe the the Java language and bytecode definitions
`are weaker than they should be from a security viewpoint.
`The language has neither a formal semantics nor a formal
`description of its type system. The module system is weak,
`the scoping rules are 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 local file system. The separation of object creation and
`initialization poses problems. We believe the system could
`be stronger if it were designed differently.
`
`Language Weaknesses The Java language has neither a
`form a1 semantics nor a formal description of its type system.
`We do not know what a Java program means, in any formal
`sense, so we cannotformally reason about Java and the secu-
`rity properties of the Java libraries written in Java. Java lacks
`a formal description of its type sy