`
`Insik Shin
`ishin(cid:2)cs(cid:3)stanford(cid:3)edu
`
`John C(cid:2) Mitchell
`mitchell(cid:2)cs(cid:3)stanford(cid:3)edu
`
`Computer Science Department
`Stanford University
`Stanford(cid:3) CA
`
`Abstract
`
`While the Java Virtual Machine includes a bytecode veri(cid:2)er that checks bytecode
`programs before execution(cid:3) and a bytecode interpreter that performs run(cid:4)time tests
`such as array bounds and null(cid:4)pointer checks(cid:3) Java applets may still behave in ways
`that are annoying or potentially harmful to users(cid:5) For example(cid:3) applets may mount
`denial(cid:4)of(cid:4)service attacks(cid:3) forge email or display misleading information in order to trick
`users(cid:5) With these concerns in mind(cid:3) we present techniques that may be used to insert
`additional run(cid:4)time tests into Java applets(cid:5) These techniques may be used to restrict
`applet behavior or(cid:3) potentially(cid:3) insert code appropriate to pro(cid:2)ling or other monitoring
`e(cid:6)orts(cid:5) The main techniques are class(cid:4)level modi(cid:2)cation(cid:3) involving subclassing non(cid:4)(cid:2)nal
`classes(cid:3) and method(cid:4)level modi(cid:2)cation(cid:3) which may be used when control over objects
`from (cid:2)nal classes is desired(cid:5)
`
`Subject Areas(cid:2) language design and implementation(cid:2) analysis and design meth(cid:3)
`ods(cid:2) software engineering practices(cid:2) experienced with object(cid:3)oriented applica(cid:3)
`tions and systems(cid:2) security(cid:4)
`
` Introduction
`
`The Java Language (cid:5) (cid:8) has proven useful for a variety of purposes(cid:2) including system de(cid:3)
`velopment and the addition of (cid:9)active content(cid:10) to web pages(cid:4) Although previous language
`implementations(cid:2) such as Pascal and Smalltalk systems(cid:2) have used intermediate bytecode(cid:2)
`the use of bytecode as a medium of exchange places Java bytecode in a new light(cid:4) To protect
`against execution of erroneous or potentially malicious code(cid:2) the Java Virtual Machine ver(cid:3)
`i(cid:11)es code properties before execution and performs additional checks at run time(cid:4) However(cid:2)
`
`(cid:0)submitted to OOPLSA (cid:2)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 1
`
`
`
`these tests will not protect against certain forms of undesirable run(cid:3)time behavior(cid:2) such
`as denial(cid:3)of(cid:3)service attacks(cid:2) irritating audio sounds(cid:2) or violation of conventions regarding
`hypertext links(cid:4) Moreover(cid:2) users cannot easily customize the tests that are performed since
`these are built into the Java Virtual Machine(cid:4)
`
`The goal of our work is to develop methods for enforcing applet properties(cid:2) in a manner
`that may be customized easily(cid:4)
`In this paper(cid:2) we propose a technique(cid:2) called bytecode
`modi(cid:3)cation(cid:2) through which we put restrictions on applets by inserting additional bytecode
`instructions that will perform the necessary run(cid:3)time tests(cid:4) These additional instructions
`may monitor and control resource usage(cid:2) limit applet functionality(cid:2) or provide control over
`inaccessible objects(cid:4) While our techniques bear some relation to software fault isolation (cid:5) (cid:8)(cid:2)
`we check di(cid:13)erent properties and our code operations are speci(cid:11)cally tailored to the (cid:11)le
`structure and commands of the Java Language(cid:4) Our technique falls into two parts(cid:14) class(cid:4)
`level modi(cid:11)cation and method(cid:4)level modi(cid:11)cation(cid:4) In class(cid:3)level modi(cid:11)cation(cid:2) references to
`one class are modi(cid:11)ed to refer to another class(cid:4) Since this method relies on class inheritance
`and subtyping(cid:2) it is simple and fast(cid:2) but can not be applied to (cid:11)nal classes and interfaces(cid:4)
`In these cases(cid:2) method(cid:3)level modi(cid:11)cation is used since it may be applied on a method(cid:3)by(cid:3)
`method basis without regard to class hierarchy restrictions(cid:4)
`
`We have implemented our techniques in an HTTP proxy server that modi(cid:11)es classes
`before they are received by the browser(cid:4) Although the proxy structure provides an easy
`way to test our approach(cid:2) it is not completely comprehensive since(cid:2) for example(cid:2) encrypted
`applets from secure pages are not accessible to the proxy(cid:4) For this reason(cid:2) it might also be
`useful to implement bytecode modi(cid:11)cation facilities in the browser or virtual machine(cid:2) or
`by an extension of the class loader(cid:4) Our proxy server is controlled by a user interface that
`runs as a Java applet and may be con(cid:11)gured to block access to a speci(cid:11)c sites(cid:2) redirect
`requests for special Java classes or eliminate tagged advertisements(cid:4)
`
`In Section (cid:2) we discuss several example Java applet attacks that require techniques
`beyond the current Java veri(cid:11)er and security model(cid:4) We explain the bytecode modi(cid:11)cation
`techniques in Section and present some examples in Section (cid:4) Experimental performance
`data appears in Section (cid:2) with comparison to related work on safe execution of Java applets
`in Section (cid:4) We conclude in Section (cid:4)
`
` Java Applet Safety
`
`Before describing a series of techniques for modifying Java bytecode programs(cid:2) we give
`some motivating examples of hazardous or undesirable Java applets(cid:4) Each of the problems
`outlined in this section can be eliminated or contained using our approach(cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 2
`
`
`
`(cid:2) Denial of Service Attack
`
`The Java Virtual Machine provides little protection against denial of service attacks(cid:4) An
`applet can make the system unstable by monopolizing CPU time(cid:2) allocating memory until
`the system runs out(cid:2) or starving other threads and system processes(cid:4) For example(cid:2) an applet
`may create huge black windows on the screen in such a way that the users cannot access
`other parts of the screen(cid:2) or it may open a large number of windows (cid:5)(cid:8)(cid:4) Many machines
`have limits on the number of windows that can be open at one time and may crash if these
`limits are exceeded(cid:4) Since the safety of the Java runtime system may be threatened by
`inordinate system resource use(cid:2) it is useful to have some mechanism to monitor and control
`resource usage(cid:4)
`
`(cid:2) Disclosure of Con(cid:4)dential Information Attack
`
`There are many ways that an applet may communicate information to another site on the
`network(cid:4) For example(cid:2) browsers such as Navigator(cid:2) Internet Explorer and HotJava provide
`a network security mode which allows an applet to connect to the web server from which it
`was loaded(cid:4) In addition(cid:2) there are a variety of covert channels that are di(cid:19)cult to detect(cid:4)
`One example involves the URL redirect feature(cid:4) Normally(cid:2) an applet may instruct the
`browser to load any page on the web(cid:4) An attacker(cid:20)s server could record the URL as a
`message(cid:2) then redirect the browser to the original destination (cid:5) (cid:8)(cid:4) Time(cid:3)delayed access to
`(cid:11)les also can be used as a covert channel (cid:5) (cid:8)(cid:4) Speci(cid:11)cally(cid:2) if an applet(cid:2) A(cid:2) with access to
`private information is prohibited from accessing the net(cid:2) information can still be sent out
`by another applet(cid:2) B(cid:2) which shares a (cid:11)le with applet A(cid:4)
`
`While it seems di(cid:19)cult to eliminate all possible covert channels(cid:2) some may be prevented
`using our techniques(cid:4) An example we discuss later in the paper is forged email(cid:4)
`If a
`web server is running an SMTP mail daemon(cid:2) an applet can interact with sendmail after
`connecting to port on the web server(cid:4) This allows a hostile applet to forge email(cid:4) This
`form of email forgery may be prevented by disallowing connections to port (cid:4) Inter(cid:3)applet
`communications using storage channels can be detected by monitoring the actions of applets
`through logging facilities(cid:4)
`
`(cid:2) Spoo(cid:4)ng Attack
`
`In a spoo(cid:11)ng attack(cid:2) an attacker creates a misleading context in order to trick a user into
`making an inappropriate security(cid:3)relevant decision (cid:5)(cid:8)(cid:4) Some applets display the URL that
`will be accessed when the the mouse is held over a graphic or link(cid:4) By convention(cid:2) the URL
`is shown in a speci(cid:11)c position on the status line(cid:4) If an applet displays a fake URL(cid:2) the user
`can be misled(cid:4) This could allow an applet to mislead a user into connecting to a site that
`is hazardous in some way(cid:4) Fortunately(cid:2) this spoo(cid:11)ng attack can be controlled by enforcing
`conventions about the URL displayed on the status line(cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 3
`
`
`
`(cid:2) Annoyance Attack
`
`An applet can annoy users with a very noisy sound which never ends(cid:4) This form of sound
`attack exploits a useful feature of Java(cid:2) the ability to play sound in the background(cid:4) To
`eliminate an annoying sound(cid:2) however(cid:2) users typically must kill the thread playing sound(cid:2)
`disable the audio(cid:2) or quit the browser(cid:4) All of these can be inconvenient(cid:4) Another possible
`annoyance attack is to make the browser visit a given web site over and over(cid:2) popping up a
`new copy of the browser each time(cid:4) One way to manage annoying sounds is to provide the
`ability to turn the sound o(cid:13)(cid:4) To do so(cid:2) the Java runtime system must monitor and control
`objects with sound(cid:4) Similar methods can be used to handle repeated visits to a certain site(cid:2)
`and other annoyance attacks(cid:4)
`
` Java Bytecode Modi(cid:4)cation
`
`This paper presents a safety mechanism for Java applets that is su(cid:19)cient to solve the
`problems summarized above(cid:4) The basic idea is to put restrictions on applets by inserting
`safeguarding code(cid:4)
`In the examples we have implemented and tested(cid:2) safeguarding code
`may monitor and control resource usage as well as limit the functionality of applets(cid:4) Our
`techniques bear some relation to software fault isolation (cid:5) (cid:8)(cid:2) but involve di(cid:13)erent run(cid:3)time
`properties(cid:4)
`In addition(cid:2) our code operations are speci(cid:11)cally tailored to the (cid:11)le structure
`and commands of the Java Language(cid:4)
`
`Our safety mechanism substitutes one executable entity(cid:2) such as a class or a method(cid:2)
`with a related executable entity that performs additional run(cid:3)time tests(cid:4) For instance(cid:2)
`a class such as Window can be replaced with a more restrictive class Safe(cid:2)Window that
`performs additional security and sanity checks(cid:4) (cid:22)We use the pre(cid:11)x Safe(cid:2) to indicate one of
`our safe classes(cid:4)(cid:23) This safety mechanism must be applied before the applet is executed(cid:4) For
`convenience in developing a proof of concept(cid:2) applets are currently modi(cid:11)ed within an HTTP
`proxy server that sits between a web server and a client browser(cid:4) This implementation does
`not require any changes in the web server(cid:2) Java Virtual Machine or web browser(cid:4) Since
`applets and the browser are not noti(cid:11)ed of changes in the applet(cid:2) subsequent requests for
`safeguarded executable entities may be issued to the web server(cid:2) which does not have them(cid:4)
`This problem is handled by having the proxy redirect these requests to cites where the
`safeguarding entities are actually stored(cid:4)
`
`The following sections explain how modi(cid:11)ed executable entities are inserted in Java
`bytecode(cid:4) The modi(cid:11)cations may be divided into two general forms(cid:2) class(cid:3)level and method(cid:3)
`level modi(cid:11)cations(cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 4
`
`
`
`class name index
`
`CONSTANT_Class entry
`
`class name
`
`CONSTANT_Utf8 entry
`
`CONSTANT POOL
`
`Figure (cid:14) A class is represented with two entries in the constant pool
`
` (cid:2) Class(cid:7)level Modi(cid:4)cation
`
`A class such as Window can be replaced with a subclass of Window (cid:22)which will be called
`Safe(cid:2)Window in this example(cid:23) that restricts resource usage and functionality(cid:4) For example(cid:2)
`Safe(cid:2)Window(cid:20)s constructor method can put a limit on how many windows can be open on
`the screen(cid:4) The method allows new windows to be created until the number of windows
`exceeds the limit(cid:4) If the limit is exceeded(cid:2) the method throws an exception indicating that
`too many windows are open(cid:4) Since Safe(cid:2)Window is a subtype of Window(cid:2) type Safe(cid:2)Window
`can appear anywhere type Window is expected(cid:4) Hence(cid:2) the applet should not notice the
`change(cid:2) unless it attempts to create windows exceeding the limit(cid:4)
`
`This example of class(cid:3)level substitution is done by merely substituting references to class
`Window with references to class Safe(cid:2)Window(cid:4) In Java(cid:2) all references to strings(cid:2) classes(cid:2)
`(cid:11)elds(cid:2) and methods are resolved through indices into the constant pool of the class (cid:11)le (cid:5)(cid:8)(cid:2)
`where their symbolic names are stored(cid:4) Therefore(cid:2) it is the constant pool that should be
`modi(cid:11)ed in a Java class (cid:11)le(cid:4) In more detail(cid:2) two entries are used to represent a class in the
`constant pool(cid:4) A class is represented by a constant pool entry tagged as CONSTANT Class
`which refers to a CONSTANT Uft entry for a UTF(cid:3) string representing a fully quali(cid:11)ed
`name of the class(cid:2) as shown in Figure (cid:4)
`
`If we replace a class name of a CONSTANT Uft entry(cid:2) Window(cid:2) with a new class name(cid:2)
`Safe(cid:2)Window(cid:2) the CONSTANT Class entry will represent the new class(cid:2) Safe(cid:2)Window(cid:2) as
`shown in Figure (cid:4)
`
`Class(cid:3)level substitution requires a simple modi(cid:11)cation of a constant pool entry(cid:2) since it
`takes advantage of the property of class inheritance(cid:4) Obviously(cid:2) however(cid:2) the use of class
`inheritance prevents this approach from being applied to (cid:11)nal classes or interfaces(cid:4)
`
` The Unicode Standard(cid:5) version (cid:7) (cid:5) and ISO(cid:8)IEC (cid:12) (cid:13) jointly de(cid:15)ne a bit character set
`which encompasses most of the world(cid:2)s writing system(cid:7) UTF(cid:12)(cid:5) one of UCS transformation formats(cid:5) has
`been developed for the compatibility between the (cid:12)bit characters and many applications and protocols for
`the US(cid:12)ASCII characters(cid:7) For more information regarding the UTF(cid:12) format(cid:5) see File System Safe UCS
`Transformation Format (cid:2)UTF(cid:3)(cid:5)(cid:5) X(cid:8)Open Preliminary Speci(cid:15)cation(cid:5) X(cid:8)Open Company Ltd(cid:7)(cid:5) Document
`Number(cid:13) P (cid:7)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 5
`
`
`
`11
`
`101
`
`11
`
`101
`
`101
`
`java/awt/Window
`
`101
`
`Safe$Window
`
`Before
`
`After
`
`Figure (cid:14) Class(cid:3)level modi(cid:11)cation substitutes class reference
`
` (cid:2) Method(cid:7)level Modi(cid:4)cation
`
`To address the limitation of class(cid:3)level modi(cid:11)cation(cid:2) method(cid:3)level modi(cid:11)cation replaces a
`method with a related method without making use of the class hierarchy structure(cid:4) This
`approach provides more (cid:25)exibility in that it can be used even when the method is (cid:11)nal or
`is accessed through an interface(cid:2) but requires more complicated modi(cid:11)cations of method
`reference and method invoking instructions(cid:4)
`
`Before getting into more details(cid:2) we show a brief description of a (cid:11)eld and a method
`descriptor in Java class (cid:11)le format(cid:4) The (cid:11)eld descriptor represents the type of a class or
`instance variable(cid:4) For example(cid:2) the descriptor of an int instance variable is simply I(cid:4) Table
` shows the meaning of some (cid:11)eld descriptors(cid:4)
`
`Descriptor
`C
`I
`Z
`L(cid:2)classname(cid:3)(cid:26)
`
`Type
`character
`integer
`boolean
`an instance of the class
`
`Table (cid:14) The meaning of the (cid:11)eld descriptor
`
`The Method descriptor represents the parameters that the method takes and the value
`that it returns(cid:4) A parameter descriptor represents zero or more (cid:11)eld types(cid:4) A return
`descriptor represents a (cid:11)eld type or V(cid:4) The character V indicates that the method returns
`no value(cid:22)void(cid:23)(cid:4) For example(cid:2) the method descriptor for the method void foo (cid:3)Thread
`t(cid:4) int i(cid:5) is (cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V(cid:4)
`
`Before explaining how method invoking instructions are modi(cid:11)ed(cid:2) we also show how a
`method is compiled into a class (cid:11)le through the following example(cid:2) which gives you the
`intuituion about what bytecodes look like(cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 6
`
`
`
`The method
`
`void foo (cid:3)Thread t(cid:4) int i(cid:5) f
`t(cid:8)setPriority (cid:3)i(cid:5)(cid:7)
`
`g
`
`compiles to
`
`Method public foo(cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V
`push Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)v
`push I
`invokevirtual Thread(cid:8)setPriority(cid:3)I(cid:5)V
`
`We are going to explain method(cid:3)level modi(cid:11)cation with this example(cid:2) trying to replace
`Thread(cid:8)setPriority(cid:3)I(cid:5)V with a more restrictive method(cid:2) for instance(cid:2) called Safe(cid:2)(cid:9)
`Thread(cid:8)setPriority(cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V(cid:2) which does not allow an applet to have
`higher priority than a new upper limit de(cid:11)ned in class Safe(cid:2)Thread(cid:4) Since the new safe(cid:3)
`guarding method invokes the instance method of class Thread(cid:2) a reference to an instance
`of class Thread should be passed to the new method(cid:4) For instance(cid:2) t(cid:8)setPriority(cid:3)(cid:5)
`becomes Safe(cid:2)Thread(cid:8)setPriority(cid:3)t(cid:4)(cid:5)(cid:4) The new method takes priority of type in(cid:3)
`teger as one of its arguments(cid:2) and compares it with its upper limit(cid:4)
`If the argument
`is higher(cid:2) the argument is set to the upper limit(cid:4) Eventually(cid:2) the new method invokes
`Thread(cid:8)setPriority(cid:3)I(cid:5)V with the veri(cid:11)ed argument(cid:4)
`
` (cid:2)(cid:2) Method Reference Modi(cid:5)cation
`
`A method of a class (cid:22)a static method(cid:23) or of a class instance (cid:22)an instance method(cid:23) is repre(cid:3)
`sented by a constant pool entry tagged as CONSTANT Methodref(cid:4) The CONSTANT Methodref
`entry refers to the CONSTANT Class entry(cid:2) representing the class of which the method is
`a member(cid:2) and the CONSTANT NameAndType entry(cid:2) representing the name and descrip(cid:3)
`tor of the method(cid:2) as shown in Figure (cid:22)a(cid:23)(cid:4) In our example(cid:2) the CONSTANT Class entry
`and the CONSTANT NameAndType entry refer to the CONSTANT Uft entries representing
`java(cid:6)lang(cid:6)Thread(cid:2) setPriority(cid:2) and (cid:3)I(cid:5)V(cid:2) respectively(cid:4)
`
`Since a new class(cid:2) Safe(cid:2)Thread(cid:2) appears(cid:2) we should add a new CONSTANT Uft en(cid:3)
`try representing a string for the new class name(cid:2) and another new CONSTANT Class en(cid:3)
`try referencing the new CONSTANT Uft entry(cid:4) Then the CONSTANT Methodref entry is
`modi(cid:11)ed to refer to the new CONSTANT Class entry instead of an old CONSTANT Class
`entry which is representing class java(cid:6)lang(cid:6)Thread(cid:4) Since a method descriptor changes(cid:2)
`we also need to add a CONSTANT Uft entry representing a symbolic name for the new
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 7
`
`
`
`CONSTANT_Class
`
`entry
`
`CONSTANT_Methodref
`
`entry
`
`CONSTANT_NameAndType
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Class
`
`entry
`
`CONSTANT_Methodref
`
`entry
`
`CONSTANT_NameAndType
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Utf8
`
`entry
`
`CONSTANT_Utf8
`entry
`CONSTANT_Class
`entry
`CONSTANT_Utf8
`entry
`
`- - - - - -
`
`- - - - - - - - -
`
`11
`21
`
`31
`
`101
`
`111
`
`121
`
`101
`
`11
`
`111
`
`31
`
`121
`
`java/lang/Thread
`
`setPriority
`
`(I)V
`
`(a) reference to
`
`Thread.setPriority(I)V
`
`11
`
`21
`
`31
`
`101
`
`111
`
`121
`
`201
`202
`203
`
`101
`
`202
`
`111
`
`31
`
`203
`
`java/lang/Thread
`
`setPriority
`
`(I)V
`
`Safe$Thread
`
`201
`
`(Ljava/lang/Thread;I)V
`
`(b) reference to
`
`Safe$Thread.setPriority(Ljava/lang/Thread;I)V
`
`Figure (cid:14) Method(cid:3)level modi(cid:11)cation substitutes method reference
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 8
`
`
`
`method descriptor(cid:2) (cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V(cid:4) Then the CONSTANT NameAndType entry
`is modi(cid:11)ed to refer to the new CONSTANT Uft entry for the method descriptor(cid:4) Now the
`CONSTANT Methodref entry represents a new method(cid:2) Safe(cid:2)Thread(cid:8)setPriority(cid:3)Lja(cid:9)
`va(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V(cid:2) as shown in Figure (cid:22)b(cid:23)(cid:4)
`
` (cid:2)(cid:2) Method Invoking Instruction Modi(cid:5)cation
`
`Among various Java Virtual Machine instructions implementing method invocations(cid:2) we
`are interested in invokevirtual for an instance method invocation and invokestatic for
`a class(cid:22)static(cid:23) method invocation in this example(cid:4) Both instructions take as an argument
`an index to a CONSTANT Methodref constant pool entry(cid:2) but their operand stacks are
`di(cid:13)erent(cid:4)
`
`The instance method invocation is set up by (cid:11)rst pushing a reference to the instance
`which the method belongs to onto the operand stack(cid:4) The method invocation(cid:20)s arguments
`are then pushed(cid:4) Figure (cid:22)a(cid:23) shows the operand stack and instruction sequences for the
`instance method call to Thread(cid:8)setPriority(cid:3)I(cid:5)V(cid:4) The argument of invokevirtual is the
`index in Figure (cid:22)a(cid:23)(cid:4)
`
`The class method invocation requires only arguments to be pushed onto the operand
`stack(cid:4) The operand stack and instruction sequences for the instance method call to Safe(cid:2)(cid:9)
`Thread(cid:8)setPriority(cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V are shown in Figure (cid:22)b(cid:23)(cid:4) The argument
`of invokestatic is the index in Figure (cid:22)b(cid:23)(cid:4)
`
`While the operand stacks and push instructions and their arguments in Figure (cid:22)a(cid:23) and
`(cid:22)b(cid:23) are the same(cid:2) the instruction for method invocation is di(cid:13)erent(cid:4) Hence(cid:2) the new method
`Safe(cid:2)Thread(cid:8)setPriority(cid:3)Ljava(cid:6)lang(cid:6)Thread(cid:7)I(cid:5)V can be added into the bytecode pro(cid:3)
`gram with a change from invokevirtual to invokestatic(cid:4)
`
`In this section(cid:2) we covered the details of how the two bytecode modi(cid:11)cation techniques
`work(cid:4) While class(cid:3)level modi(cid:11)cation requires a simple modi(cid:11)cation in the constant pool(cid:2)
`method(cid:3)level modi(cid:11)cation requires bytecode instruction modi(cid:11)cations as well as constant
`pool modi(cid:11)cations(cid:4) Essentially(cid:2) class(cid:3)level modi(cid:11)cation requires only (cid:3) (cid:27) of computation
`of method(cid:3)level modi(cid:11)cation depending on the relative size of the constant pool(cid:4) However(cid:2)
`class(cid:3)level modi(cid:11)cation can not be applied to (cid:11)nal classes or interfaces which method(cid:3)level
`modi(cid:11)cation may be applied to(cid:4)
`
` Examples for Applet Security
`
`In this section(cid:2) we outline several examples of using bytecode modi(cid:11)cation technique for
`protecting against malicious attacks mentioned in Section (cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 9
`
`
`
`top
`
`I
`Ljava/lang/Thread;
`
`push instance Ljava/lang/Thread;
`
`(instance)
`
`push argument I
`
`(argument)
`
`invokevirtual
`
`#21
`
` Operand Stack
`(a) Instance method invocation of Thread.setPriority(I)V
`
`top
`
`I
`Ljava/lang/Thread;
`
`push instance Ljava/lang/Thread;
`
`(argument)
`
`push argument I
`
`(argument)
`
`invokestatic
`
`#21
`
` Operand Stack
`(b) Class method invocation of
`
`Safe$Thread.setPriority(Ljava/lang/Thread;I)V
`
`Figure (cid:14) Operand stack and instruction sequences for method invoking instructions
`
`(cid:2) Window Consuming Attack
`
`An applet can crash the system by creating more windows than the windowing system can
`handle(cid:4) To protect against this resource consuming attack(cid:2) the safety mechanism should
`keep track of window creation(cid:4)
`
`A Java library class(cid:2) Frame(cid:2) handles an optionally resizable top(cid:3)level window(cid:4) The
`constructor methods create a window(cid:4) The key to the solution to this attack is to disallow
`an applet to invoke the constructor methods more than a certain number of times(cid:4)
`
`Since Frame is not (cid:11)nal(cid:2) a subclass Safe(cid:2)Frame can be generated(cid:2) in such a way that
`Safe(cid:2)Frame can monitor and control every window generation(cid:4) Safe(cid:2)Frame can create
`windows using the constructor methods of Frame while counting the current number of
`open windows(cid:4) It should not create a window if the number of windows exceeds its own
`limit(cid:4) Class(cid:3)level modi(cid:11)cation is used to substitute references to Frame with references to
`Safe(cid:2)Frame(cid:4) This technique may also restrict window size and window positions(cid:4)
`
`(cid:2) Email Forging Attack
`
`An applet is able to disclose the user(cid:20)s con(cid:11)dential information through email(cid:2) while its
`web server is running an SMTP mail daemon(cid:4) To prevent access to this covert channel(cid:2) the
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 10
`
`
`
`applet should not be able to connect to port on the web server(cid:4)
`
`A Java library class(cid:2) Socket(cid:2) implements a socket for interprocess communication over
`the network(cid:4) The constructor methods create the socket and connect it to the speci(cid:11)ed
`host and port(cid:4) Since we want to put restrictions on the constructor methods(cid:2) we should
`be familiar with how constructor method invocation is implemented in the Java Virtual
`Machine(cid:22)JVM(cid:23)(cid:4)
`
`JVM class instances are created using the JVM(cid:20)s new instruction(cid:4) Once the class instance
`has been created and its instance variables have been initialized to their default values(cid:2) an
`instance initialization method of the new class instance(cid:22)(cid:2)init(cid:3)(cid:23) is invoked(cid:4) At the level
`of the JVM(cid:2) a constructor appears as a method with the special compiler(cid:3)supplied name
`(cid:2)init(cid:3)(cid:4) For example(cid:14)
`
`Socket create(cid:3)(cid:5) f
`return new Socket(cid:3)host name(cid:4) port number(cid:5)(cid:7)
`
`g
`
`compiles to
`
`Method java(cid:8)net(cid:8)Socket create(cid:3)(cid:5)
`
`new (cid:11)
`Class java(cid:8)net(cid:8)Socket
`
`dup
`Field this(cid:8)host name java(cid:8)lang(cid:8)String
`
`getfield
`Field this(cid:8)port number I
`
`getfield
`
`invokespecial (cid:11) Method java(cid:8)net(cid:8)Socket(cid:8)(cid:14)init(cid:15)(cid:3)Ljava(cid:6)(cid:9)
`lang(cid:6)String(cid:7)I(cid:5)V
`
`
`
`areturn
`
`invokespecial is the Java Virtual Machine instruction for instance initialization method
`invocations(cid:4) It invokes instance methods requiring special handling(cid:2) such as superclass(cid:2) pri(cid:3)
`vate(cid:2) or instance initialization methods(cid:4)
`
`Since Socket is a (cid:11)nal class in the browser(cid:2) we replace the constructor methods through
`method(cid:3)level modi(cid:11)cation(cid:4) Our static safe method(cid:2) Safe(cid:2)Socket(cid:8)init(cid:2) which is a class
`method(cid:2) can monitor and control every socket connection(cid:4) Safe(cid:2)Socket(cid:8)init establishes
`the socket connection upon every request excluding a request to port (cid:2) and return a new
`socket object(cid:4) It refuses the request to port (cid:4) Safe(cid:2)Socket(cid:8)init takes the same argument
`type as whatever the constructor of Socket takes(cid:2) but returns a di(cid:13)erent return type since
`it returns the new socket object(cid:4) So references to Socket(cid:8)(cid:14)init(cid:15)(cid:3)Ljava(cid:6)lang(cid:6)String(cid:7)I(cid:5)V
`are replaced with references to Safe(cid:2)Socket(cid:8)init(cid:3)Ljava(cid:6)lang(cid:6)String(cid:7)I(cid:5)Ljava(cid:6)net(cid:6)Socket(cid:7)(cid:4)
`
`Since Safe(cid:2)Socket(cid:8)init is a static method(cid:2) we replace invokespecial with invokestatic(cid:4)
`In addition(cid:2) we should remove a socket object created by new from the stack(cid:2) since the new
`method returns a socket object(cid:4) The modi(cid:11)ed codes are as follows(cid:14)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 11
`
`
`
`Method java(cid:8)net(cid:8)Socket create(cid:3)(cid:5)
`
`new (cid:11)
`Class java(cid:8)net(cid:8)Socket
`pop
`
`Field this(cid:8)host name java(cid:8)lang(cid:8)String
`
`getfield
`Field this(cid:8)port number I
`
`getfield
`invokestatic (cid:11) Method Safe(cid:2)Socket(cid:8)(cid:14)init(cid:15)(cid:3)Ljava(cid:6)lang(cid:6)(cid:9)
`
`String(cid:7)I(cid:5)Ljava(cid:6)lang(cid:6)Socket(cid:7)
`
`
`
`areturn
`
`(cid:2) URL Spoo(cid:4)ng Attack
`
`An applet can spoof a user with a fake URL display on the status line(cid:4) This spoo(cid:11)ng attack
`is protected by checking the consistency between the URL displayed and the URL from
`which a Web page is actually to be loaded(cid:4)
`
`A Java library interface(cid:2) AppletContext(cid:2) de(cid:11)nes the methods that allow an applet
`to interact with the context in a Web browser or an applet viewer(cid:4) The showDocument
`method requests that the browser or applet viewer show the Web page indicated by the
`URL argument(cid:4) The showStatus method displays text in the Web browser or applet
`viewer(cid:20)s status line(cid:4) Safe(cid:2)AppletContext(cid:8)showStatus(cid:2) which is our static safe method for
`the showStatus method(cid:2) saves the current text in addition to displaying it so that another
`our safe method(cid:2) Safe(cid:2)AppletContext(cid:8)showDocument(cid:2) can refer to the text later(cid:4) When
`Safe(cid:2)AppletContext(cid:8)showDocument is invoked(cid:2) it (cid:11)rst examines whether or not the URL
`argument is equals to the text which is currently displayed on the status line(cid:4) If so(cid:2) the
`method requests the browser to bring the Web page indicated by the URL argument(cid:4) If
`not(cid:2) the method displays the URL argument on the status line(cid:2) instead of passing on the
`request(cid:4) In the latter case(cid:2) the users may notice the inconsistency(cid:2) and take an appropriate
`action(cid:4) In general(cid:2) the users can get the Web page loaded with one more mouse click(cid:4) This
`guarantees that the users bring a new Web page with its URL displayed on the status line(cid:4)
`Its positive side e(cid:13)ect is that it displays the URL when the URL is not available(cid:4)
`
`Since the AppletContext interface is not inheritable(cid:2) the two interface methods must
`be replaced through the method(cid:3)level modi(cid:11)cation(cid:4) References to AppletContext(cid:8)show(cid:9)
`Status(cid:3)S(cid:5)V and AppletContext(cid:8)showDocument(cid:3)Ljava(cid:6)net(cid:6)URL(cid:7)(cid:5)V is substituted with
`references to Safe(cid:2)AppletContext(cid:8)showStatus(cid:3)S(cid:5)V and Safe(cid:2)AppletContext(cid:8)showDocu(cid:9)
`ment(cid:3)Ljava(cid:6)net(cid:6)URL(cid:7)(cid:5)V respectively(cid:4)
`
`invokeinterface is the instruction for invoking an interface method(cid:4) Since the in(cid:3)
`terface methods are substituted with the static methods(cid:2) invokeinterface is also re(cid:3)
`placed with invokestatic(cid:4) Since invokestatic does not have the last two operands of
`invokeinterface(cid:2) the two operands should be assigned to the nop instruction(cid:4)
`
`
`
`Blue Coat Systems - Exhibit 1009 Page 12
`
`
`
`Figure (cid:14) A pop(cid:3)up window for controlling a sound object
`
`(cid:2) Annoying Sound Attack
`
`An applet can annoy the user with never(cid:3)ending sounds(cid:4) To prevent this annoyance attack(cid:2)
`the user should be allowed to turn sounds o(cid:13)(cid:4) The solution is to keep track of every sound
`object(cid:4)
`
`A Java library interface(cid:2) AudioClip(cid:2) describes the essential methods for playing a sound(cid:4)
`AppletContext(cid:8)getAudioClip(cid:3)(cid:5) and Applet(cid:8)getAudioClip(cid:3)(cid:5) both return an object that
`implements this interface(cid:4) The loop method of the object starts playing the audio clip in
`a loop(cid:2) and the stop method stops playing the audio clip(cid:4) The attack is implemen