Secure the Clones * Static Enforcement of Policies for Secure Object Copying Companion Report. Thomas Jensen, Florent Kirchner, and David Pichardie

Transcription

1 Secure the Clones * Static Enorcement o Policies or Secure Object Copying Companion Report Thomas Jensen, Florent Kirchner, and David Pichardie INRIA Rennes Bretagne Atlantique, France irstname.lastname@inria.r Abstract. Exchanging mutable data objects with untrusted code is a delicate matter because o the risk o creating a data space that is accessible by an attacker. Consequently, secure programming guidelines or Java stress the importance o using deensive copying beore accepting or handing reerences to an internal mutable object. However, implementation o a copy method (like clone()) is entirely let to the programmer. It may not provide a suiciently deep copy o an object and is subject to overriding by a malicious sub-class. Currently no language-based mechanism supports secure object cloning. This paper proposes a type-based annotation system or deining modular copy policies or class-based object-oriented programs. A copy policy speciies the maximally allowed sharing between an object and its clone. We present a static enorcement mechanism that will guarantee that all classes ulill their copy policy, even in the presence o overriding o copy methods, and establish the semantic correctness o the overall approach in Coq. The mechanism has been implemented and experimentally evaluated on clone methods rom several Java libraries. 1 Introduction Exchanging data objects with untrusted code is a delicate matter because o the risk o creating a data space that is accessible by an attacker. Consequently, secure programming guidelines or Java such as those proposed by Sun [13] and CERT [5] stress the importance o using deensive copying or cloning beore accepting or handing reerences to an internal mutable object. There are two aspects o the problem: 1. I the result o a method is a reerence to an internal mutable object, then the receiving code may modiy the internal state. Thereore, it is recommended to make copies o mutable objects that are returned as results, unless the intention is to share state. 2. I an argument to a method is a reerence to an object coming rom hostile code, a local copy o the object should be created. Otherwise, the hostile code may be able to modiy the internal state o the object. * This work was supported by the ANSSI, the ANR, and the Région Bretagne, respectively under the Javasec, Parsec, and Certlogs projects.

2 A common way or a class to provide acilities or copying objects is to implement a clone() method that overrides the cloning method provided by java.lang.object. The ollowing code snippet, taken rom Sun s Secure Coding Guidelines or Java, demonstrates how a date object is cloned beore being returned to a caller: public class CopyOutput { private inal java.util.date date;... public java.util.date getdate() { return (java.util.date)date.clone(); } } However, relying on calling a polymorphic clone method to ensure secure copying o objects may prove insuicient, or two reasons. First, the implementation o the clone() method is entirely let to the programmer and there is no way to enorce that an untrusted implementation provides a suiciently deep copy o the object. It is ree to leave reerences to parts o the original object being copied in the new object. Second, even i the current clone() method works properly, sub-classes may override the clone() method and replace it with a method that does not create a suiciently deep clone. For the above example to behave correctly, an additional class invariant is required, ensuring that the date ield always contains an object that is o class Date and not one o its sub-classes. To quote rom the CERT guidelines or secure Java programming: Do not carry deensive copying using the clone() method in constructors, when the (non-system) class can be subclassed by untrusted code. This will limit the malicious code rom returning a crated object when the object s clone() method is invoked. Clearly, we are aced with a situation where basic object-oriented sotware engineering principles (sub-classing and overriding) are at odds with security concerns. To reconcile these two aspects in a manner that provides semantically well-ounded guarantees o the resulting code, this paper proposes a ormalism or deining cloning policies by annotating classes and speciic copy methods, and a static enorcement mechanism that will guarantee that all classes o an application adhere to the copy policy. We do not enorce that a copy method will always return a target object that is unctionally equivalent to its source. Rather, we ensure non-sharing constraints between source and targets, expressed through a copy policy, as this is the security-critical part o a copy method in a deensive copying scenario. 1.1 Cloning o Objects For objects in Java to be cloneable, their class must implement the empty interace Cloneable. A deault clone method is provided by the class Object: when invoked on an object o a class, Object.clone will create a new object o that class and copy the content o each ield o the original object into the new object. The object and its clone share all sub-structures o the object; such a copy is called shallow. It is common or cloneable classes to override the deault clone method and provide their own implementation. For a generic List class, this could be done as ollows: public class List<V> implements Cloneable {

3 } public V value; public List<V> ; public List(V val, List<V> ) { this.value = val; this. = ; } public List<V> clone() { return new List(value,(==null)?null:.clone()); } Notice that this cloning method perorms a shallow copy o the list, duplicating the spine but sharing all the elements between the list and its clone. Because this amount o sharing may not be desirable (or the reasons mentioned above), the programmer is ree to implement other versions o clone(). For example, another way o cloning a list is by copying both the list spine and its elements 1, creating what is known as a deep copy. public List<V> deepclone() { return new List((V) value.clone(), (==null? null :.deepclone())); } A general programming pattern or methods that clone objects works by irst creating a shallow copy o the object by calling the super.clone() method, and then modiying certain ields to reerence new copies o the original content. This is illustrated in the ollowing snippet, taken rom the class LinkedList in Fig. 8: public Object clone() {... clone = super.clone();... clone.header = new Entry<E>(null, null, null);... return clone;} There are two observations to be made ab the analysis o such methods. First, an analysis that tracks the depth o the clone being returned will have to be low-sensitive, as the method starts with a shallow copy that is gradually being made deeper. This makes the analysis more costly. Second, there is no need to track precisely modiications made to parts o the memory that are not local to the clone method, as clone methods are primarily concerned with manipulating memory that they allocate themselves. This will have a strong impact on the design choices o our analysis. 1.2 Copy Policies The irst contribution o the paper is a proposal or a set o semantically well-deined program annotations, whose purpose is to enable the expression o policies or secure copying o objects. Introducing a copy policy language enables class developers to state explicitly the intended behavior o copy methods. In the basic orm o the copy policy ormalism, ields o classes are annotated Intuitively, the indicates that the ield is reerencing an object, parts o which 1 To be type-checked by the Java compiler it is necessary to add a cast beore calling clone() on value. A cast to a sub interace o Cloneable that declares a clone() method is necessary.

4 may be reerenced rom elsewhere. The on a ield means that a) the object reerenced by this ield cannot itsel be reerenced rom elsewhere, and b) the ield is copied according to the copy policy identiied by X. Here, X is either the name o a speciic policy or i omitted, it designates the deault policy o the class o the ield. For example, the ollowing annotations: class List V List ;...} speciies a deault policy or the class List where the ield points to a list object that also respects the deault copy policy or lists. Any method in the List class, labelled with annotation, is meant to respect this deault policy. In addition it is possible to deine other copy policies and annotate speciic copy methods (identiied by the with the name o these policies. For example, the annotation 2 DL: V List List<V> deepclone() { return new List((V) value.clone(), (==null? null :.deepclone())); } can be used to speciy a list-copying method that also ensures that the value ields o a list o objects are copied according to the copy policy o their class (which is a stronger policy than that imposed by the annotations o the class List). We give a ormal deinition o the policy annotation language in Section 2. The annotations are meant to ensure a certain degree o non-sharing between the original object being copied and its clone. We want to state explicitly that the parts o the clone that can be accessed via ields are unaccessible rom any part o the heap that was accessible beore the call to clone(). To make this intention precise, we provide a ormal semantics o a simple programming language extended with policy annotations and deine what it means or a program to respect a policy (Section 2.2). 1.3 Enorcement The second major contribution o this work is to make the developer s intent, expressed by copy policies, statically enorceable using a type system. We ormalize this enorcement mechanism by giving an interpretation o the policy language in which annotations are translated into graph-shaped type structures. For example, the annotations o the List class deined above will be translated into the graph that is depicted to the right in Fig. 1 (res is the name given to the result o the copy method). The let part shows the concrete heap structure. Unlike general purpose shape analysis, we take into account the programming methodologies and practice or copy methods, and design a type system speciically tailored to the enorcement o copy policies. This means that the underlying analysis must be able to track precisely all modiications to objects that the copy method allocates itsel (directly or indirectly) in a low-sensitive manner. Conversely, as copy methods should 2 Our implementation uses a sightly dierent policy declaration syntax because o the limitations imposed by the Java annotation language.

5 not modiy non-local objects, the analysis will be designed to be more approximate when tracking objects external to the method under analysis, and the type system will accordingly reuse methods that attempt such non-local modiications. As a urther design choice, the annotations are required to be veriiable modularly on a class-by-class basis with having to perorm an analysis o the entire code base, and at a reasonable cost. this value value value... this res value value value... res value value Fig. 1: A linked structure (let part) and its abstraction (right part). As depicted in Fig. 1, concrete memory cells are either abstracted as a) when they are not allocated in the copy method itsel (or its callee); b) when they are just marked as maybe-shared; and c) circle nodes o a deterministic graph when they are locally allocated. A single circle urthermore expresses a singleton concretization. In this example, the abstract heap representation matches the graph interpretation o annotations, which means that the instruction set that produced this heap state satisies the speciied copy policy. Technically, the intra-procedural component o our analysis corresponds to heap shape analysis with the particular type o graphs that we have deined. Operations involving non-local parts o the heap are rapidly discarded. Inter-procedural analysis uses the signatures o copy methods provided by the programmer. Inheritance is dealt with by stipulating that inherited ields retain their shallow/deep annotations. Redeinition o a method must respect the same copy policy and other copy methods can be added to a sub-class. The detailed deinition o the analysis, presented as a set o type inerence rules, is given in Section 3. 2 Language and Copy Policies The ormalism is developed or a small, imperative language extended with basic, classbased object-oriented eatures or object allocation, ield access and assignment, and method invocation. A program is a collection o classes, organized into a tree-structured class hierarchy via the extends relation. A class consists o a series o copy method declarations with each its own policy X, its name m, its ormal parameter x and commands c to execute. A sub-class inherits the copy methods o its super-class and can re-deine a copy method deined in one o its super-classes. We only consider copy methods. Private methods (or static methods o the current class) are inlined by the type checker.

6 x, y Var Field m Meth cn Class id X Policy id p Prog ::= cl cl Class ::= class cn [extends cn] {pd md} pd PolicyDecl ::= X : {τ} τ Policy ::= (X, ) md MethDecl ::= Copy(X) m(x):=c c Comm ::= x:=y x:=y. x. :=y x:=null x := new cn x:=m cn:x (y) x:=?(y) return x c; c i ( ) then c else c i while ( ) do c done Notations: We write or the relexive transitive closure o the subclass relation induced by a (well-ormed) program that is ixed in the rest o the paper. We write x a sequence o syntactic elements o orm x. Fig. 2: Language Syntax. Other method calls (to virtual methods) are modeled by a special instruction x:=?(y) that assigns an arbitrary value to x and possibly modiies all heap cells reachable rom y (except itsel). The other commands are standard. The copy method call x:=m cn:x (y) is a virtual call. The method to be called is the copy method o name m deined or inherited by the (dynamic) class o the object stored in variable y. The subscript annotation cn:x is used as a static constraint. It is supposed that the type o y is guaranteed to be a sub-class o class cn and that cn deines a method m with a copy policy X. This is ensured by standard bytecode veriication and method resolution. We suppose given a set o policy identiiers Policy id, ranged over by X. A copy policy declaration has the orm X : {τ} where X is the identiier o the policy signature and τ is a policy. The policy τ consists o a set o ield annotations (X, ) ;... where is a deep ield that should reerence an object which can only be accessed via the returned pointer o the copy method and which respects the copy policy identiied by X. The use o policy identiiers makes it possible to write recursive deinitions o copy policies, necessary or describing copy properties o recursive structures. Any other ield is implicitly shallow, meaning that no copy properties are guaranteed or the object reerenced by the ield. No urther copy properties are given or the sub-structure starting at shallow ields. For instance, the deault copy policy o the class List presented in Sec. 1.2 writes: {(List.deault, )}. We assume that or a given program, all copy policies have been grouped together in a inite map Π p : Policy id Policy. In the rest o the paper, we assume this map is complete, i.e. each policy name X that appears in an annotation is bound to a unique policy in the program p. The semantic model o the language deined here is store-based: l Loc v Val = Loc { } ρ Env = Var Val o Object = Field Val h Heap = Loc in (Class id Object) ρ, h, A State = Env Heap P(Loc)

7 A program state consists o an environment ρ o local variables, a store h o locations mapping 3 to objects in a heap and a set A o locally allocated locations in the current method or one o its callees. This last component does not inluence the semantic transitions: it is necessary to express the type system interpretation exposed in Sec. 3, but is not used in the inal soundness theorem. Each object is modeled in turn as a inite unction rom ield names to values (reerences or the speciic reerence or null values). We do not deal with base values such as integers because their immutable values are irrelevant here. (x:=y, ρ, h, A ) ρ[x ρ(y)], h, A (x:=null, ρ, h, A ) ρ[x ], h, A ρ(y) dom(h) ρ(x) dom(h) (x:=y., ρ, h, A ) ρ[x h(ρ(y), )], h, A (x. :=y, ρ, h, A ) ρ, h[(ρ(x), ) ρ(y)], A l dom(h) (x := new cn, ρ, h, A ) ρ[x l], h[l (cn, o )], A {l} (return x, ρ, h, A ) ρ[ret ρ(x)], h, A h(ρ(y)) = (cn y, ) lookup(cn y, m) = ( Copy(X ) m(a):=c ) cn y cn (c, ρ [a ρ(y)], h, ) ρ, h, A (x:=m cn:x (y), ρ, h, A ) ρ[x ρ (ret)], h, A A dom(h) dom(h ) l dom(h) \ Reach h (ρ(y)), h(l) = h (l) l dom(h) \ Reach h (ρ(y)), l, l Reach h (l ) l dom(h) \ Reach h (ρ(y)) v { } + Reach h (ρ(y)) (dom(h ) \ dom(h)) (x:=?(y), ρ, h, A ) ρ[x v], h, A\Reach + h (ρ(y)) (c 1, ρ, h, A ) ρ 1, h 1, A 1 (c 2, ρ 1, h 1, A 1 ) ρ 2, h 2, A 2 (c 1, ρ, h, A ) ρ 1, h 1, A 1 (i ( ) then c 1 else c 2 i, ρ, h, A ) ρ 1, h 1, A 1 (while ( ) do c done, ρ, h, A ) ρ, h, A (c 1; c 2, ρ, h, A ) ρ 2, h 2, A 2 (c 2, ρ, h, A ) ρ 2, h 2, A 2 (i ( ) then c 1 else c 2 i, ρ, h, A ) ρ 2, h 2, A 2 (c; while ( ) do c done, ρ, h, A ) ρ, h, A (while ( ) do c done, ρ, h, A ) ρ, h, A Notations: We write h(l, ) or the value o() such that l dom(h) and h(l) = o. We write h[(l, ) v] or the heap h that is equal to h except that the ield o the object at location l now has value v. Similarly, ρ[x v] is the environment ρ modiied so that x now maps to v. The object o is the object satisying o () = or all ield, and ρ is the environment such that ρ (x) = or all variables x. We consider methods with only one parameter and name it p. lookup designates the dynamic lookup procedure that, given a class name cn and a method name m, ind the irst implementation o m in the class hierarchy starting rom the class o name cn and scanning the hierarchy bottom-up. It returns the corresponding method declaration. ret is a speciic local variable name that is used to store the result o each method. Reach h (l) (resp. Reach + h (l)) denotes the set o values that are reachable rom any sequence (resp. any non-empty sequence) o ields in h. Fig. 3: Semantic Rules. 3 We note in or partial unctions on inite domains.

8 The operational semantics o the language is deined (Fig. 3) by the evaluation relation between conigurations Comm State and resulting states State. The set o locally allocated locations is updated by both the x := new cn and the x:=m cn:x (y) statements. The execution o an unknown method call x:=?(y) results in a new heap h that keeps all the previous objects that were not reachable rom ρ(l). It assigns the variable x a reerence that was either reachable rom ρ(l) in h or that has been allocated during this call and hence not present in h. 2.1 Policies and Inheritance We impose restrictions on the way that inheritance can interact with copy policies. A method being re-deined in a sub-class can impose urther constraints on how ields o the objects returned as result should be copied. A ield already annotated deep with policy X must have the same annotation in the policy governing the re-deined method but a ield annotated as shallow can be annotated deep or a re-deined method. Deinition 1 (Overriding Copy Policies). A program p is well-ormed with respect to overriding copy policies i and only i or any method declaration Copy(X ) m(x):=... that overrides (i.e. is declared with this signature in a subclass o a class cl) another method declaration Copy(X) m(x):=... declared in cl, we have Π p (X) Π p (X ). Example 1. The java.lang.object class provides a clone() method o policy {} (because its native clone() method is shallow on all ields). A class A declaring two ields and g can hence override the clone() method and give it a policy {(X, g)}. I a class B extends A and overrides clone(), it must assign it a policy o the orm {(X, g);... } and could declare the ield as deep. In our implementation, we let the programmer leave the policy part that concerns ields declared in superclasses implicit, as it is systematically inherited. 2.2 Semantics o Copy Policies The inormal semantics o the copy policy annotation o a method is: A copy method satisies a copy policy X i and only i no memory cell that is reachable rom the result o this method ollowing only ields with deep annotations in X, is reachable rom another local variable o the caller. We ormalize this by giving, in Fig. 4, a semantics to copy policies based on access paths. An access path consists o a variable x ollowed by a sequence o ield names i separated by a dot. An access path π can be evaluated to a value v in a context ρ, h with a judgment ρ, h π v. Each path π has a root variable π Var. A judgment π : τ holds when a path π ollows only deep ields in the policy τ. Deinition 2 (Secure Copy Method). A method m is said secure wrt. a copy signature Copy(X){τ} i and only i or all heaps h 1, h 2 Heap, local environments ρ 1, ρ 2 Env, locally allocated locations A 1, A 2 P(Loc), and variables x, y Var, (x:=m cn:x (y), ρ 1, h 1, A 1 ) ρ 2, h 2, A 2 implies ρ 2, h 2, x = τ

9 Access path syntax π P ::= x π. Access path evaluation ρ, h π l h(l) = o ρ, h x ρ(x) ρ, h π. o() Access path root x = x π. = π Access path satisying a policy We suppose given Π p : Policy id Policy the set o copy policies o the considered program p. (X 1 1) τ, (X 2 2) Π p(x 1),, (X n n) Π p(x n 1) x : τ x n : τ Policy semantics π, π P, l, l Loc, x = π, π x, ρ, h π l, ρ, h π l, implies l l π : τ ρ, h, x = τ Fig. 4: Copy Policy Semantics Note that because o virtual dispatch, the method executed by such a call may not be the method ound in cn but an overridden version o it. The security policy requires that all overriding implementations still satisy the policy τ. Lemma 1 (Monotonicity o Copy Policies wrt. Overriding). τ 1 τ 2 implies h, ρ, x, ρ, h, x = τ 2 ρ, h, x = τ 1 Proo. Under these hypotheses, or all access paths π, π : τ 1 implies π : τ 2. Thus the result holds by deinition o =. Thanks to this lemma, it is suicient to prove that each method is secure wrt. its own copy signature to ensure that all potential overridings will be also secure. 3 Type and Eect System The annotations deined in the previous section are convenient or expressing a copy policy but are not suiciently expressive or reasoning ab the data structures being copied. The static enorcement o a copy policy hence relies on a translation o policies into a graph-based structure (that we shall call types) describing parts o the environment o local variables and the heap manipulated by a program. In particular, the types can express useul alias inormation between variables and heap cells. In this section, we deine the set o types, an approximation (sub-typing) relation on types, and an inerence system or assigning types to each statement and to the inal result o a method. The set o types is deined using the ollowing symbols: n N t t = N + {,, } Γ Var t Θ P(N) = N in Field t T T = (Var t) P(N)

10 We assume given a set N o nodes. A value can be given a base type t in N + {,, }. A node n means the value has been locally allocated. The symbol means that the value is equal to the null reerence. The symbol means that the value contains a location that cannot reach a locally allocated object. The symbol is the speciic no-inormation base type. A type is a triplet T = (Γ,, Θ) T where Γ is a typing environment that maps (local) variables to base types. is a graph whose nodes are elements o N. The edges o the graphs are labeled with ield names. The successors o a node is a base type. Edges over-approximate the concrete points-to relation. Θ is a set o nodes that represents necessarily only one concrete cell each. Nodes in Θ are eligible to strong-update while others (weaks nodes) can only be weakly updated. Example 2. The deault List policy o Sec. 1.2 translates into the type Γ = [res n 1, this ] = [(n 1, ) n 2, (n 2, ) n 2, (n 1, value), (n 2, value) ] Θ = {n 1 }. As mentioned in Sec 1.3, this type enjoys a graphic representation corresponding to the right-hand side o Fig. 1. In order to link types to the heap structures they represent, we will need to state reachability predicates in the abstract domain. Thereore, the path evaluation relation is extended to types using the ollowing inerence rules: [Γ, ] x Γ (x) [Γ, ] π n [Γ, ] π. [n, ] [Γ, ] π [Γ, ] π. [Γ, ] π [Γ, ] π. Notice both and are considered as sink nodes or path evaluation purposes From Annotation to Type The set o all copy policies Π p PolicyDecl can be translated into a graph p as described hereater. We assume a naming process that associates to each policy name X Policy id o a program a unique node n X N. [ p = (n X, 1 ) n X 1,, (n X, k ) n ] X k X:{(X 1, 1);...;(X k, k )} Π p Given this graph, a policy τ = {(X 1, 1 );... ; (X k, k )} that is declared in a class cl is translated into a triplet: Φ(τ) = ( n τ, p [ (n τ, 1 ) n X 1,, (n τ, k ) n X k ], {nτ } ) 4 The sink nodes status o (resp. ) can be understood as a way to state the ollowing invariant enorced by our type system: when a cell points to an unspeciied (resp. oreign) part o the heap, all successors o this cell are also unspeciied (resp. oreign).

11 Note that we unold the possibly cyclic graph p with an extra node n τ in order to be able to catch an alias inormation between this node and the result o a method, and hence declare n τ as strong. Take or instance the type in Fig. 1: were it not or this unolding step, the type would have consisted only in a weak node and a node, with the variable res mapping directly to the ormer. Note also that it is not necessary to keep (and even to build) the ull graph p in Φ(τ) but only the part that is reachable rom n τ. 3.2 Type Interpretation The semantic interpretation o types is given in Fig. 5, in the orm o a relation ρ, h, A [Γ,, Θ] that states when a local allocation history A, a heap h and an environment ρ are coherent with a type (Γ,, Θ). The interpretation judgment amounts to checking that (i) or every path π that leads to a value l in the concrete memory and to a type t in the graph, the auxiliary type interpretation ρ, h, A, [Γ, ] v t holds; (ii) every strong node in Θ represents a uniquely reachable value in the concrete memory. The auxiliary judgment ρ, h, A, [Γ, ] v t is deined by case on t. The null value is represented by any type. The symbol represents any value and those values that do not allow to reach a locally allocated location. A node n represents a locally allocated memory location l such that every concrete path π that leads to l in ρ, h leads to node n in Γ,. Auxiliary type interpretation ρ, h, A, [Γ, ] t ρ, h, A, [Γ, ] r Reach h (l) A = ρ, h, A, [Γ, ] l Main type interpretation l A n dom(σ) π, ρ, h π l Γ, Σ π n π, t, l, } [Γ, Σ] π t ρ, h, A, [Γ, ] r t ρ, h π r ρ, h, A, [Γ, ] l n ρ, h, A [Γ,, Θ] n Θ, π, π, l, l, [Γ, Σ] π n [Γ, Σ] π } n ρ, h π l ρ, h π l l = l Fig. 5: Type Interpretation We now establish a semantic link between policy semantics and type interpretation. We show that i the inal state o a copy method can be given a type o the orm Φ(τ) then this is a secure method wrt. the policy τ. Theorem 1. Let Φ(τ) = (n τ, τ, Θ τ ), ρ Env, A P(Loc), and x Var. Assume that, or all y Var such that y is distinct rom x, A is not reachable rom ρ(y) in a

12 given heap h, i.e. Reach h (ρ(y)) A =. I there exists a state o the orm ρ, h, A, a return variable res and a local variable type Γ such that ρ (res) = ρ(x), Γ (res) = n τ and ρ, h, A [Γ, τ, Θ τ ], then ρ, h, x = τ holds. Proo. We consider two paths π and π such that x = π, π x, ρ, h π l, π : τ, ρ, h π l and look or a contradiction. Since π : τ, there exists a node n τ such that [Γ, τ ] π n. Furthermore ρ, h π l so we can deduce that l A. Thus we obtain a contradiction with ρ, h π l because any path that starts rom a variable other than x cannot reach the elements in A. 3.3 Sub-typing Value sub-typing judgment Main sub-typing judgment (ST 1) (ST 2) t t σ t σ N( 1) N( 2) + { } t t\n n N t σ σ n σ σ(n) t 1 t, π P, [Γ 1, 1] π t 1 t 2 t, t 1 σ t 2 [Γ 2, 2] π t 2 (ST 3) n 2 Θ 2, n 1 Θ 1, σ 1 (n 2) = {n 1} (Γ 1, 1, Θ 1) (Γ 2, 2, Θ 2) Fig. 6: Sub-typing To manage control low merge points we rely on a sub-typing relation described in Fig. 6. A sub-type relation (Γ 1, 1, Θ 1 ) (Γ 2, 2, Θ 2 ) holds i and only i (ST 1 ) there exists a usion unction σ rom dom( 1 ) to dom( 2 ) + { }. σ is a mapping that merges nodes and edges in 1 such that (ST 2 ) every element t 1 o 1 accessible rom a path π is mapped to an element t 2 o 2 accessible rom the same path, such that t 1 σ t 2. In particular, this means that all successors o t 1 are mapped to successors o t 2. Incidentally, because acts as a sink on paths, i t 1 is mapped to, then all its successors are mapped to too. Finally, when a strong node in 1 maps to a strong node in 2, this image node cannot be the image o any other node in 1 in other terms, σ is injective on strong nodes (ST 3 ). Intuitively, it is possible to go up in the type partial order either by merging, or by orgetting nodes in the initial graph. The ollowing example shows three ordered types and their corresponding usion unctions. On the let, we orget the node pointed to by y and hence orget all o its successors (see (ST 2 )). On the right we usion two strong nodes to obtain a weak node. x y σ1 x σ2 x

13 The logical soundness o this sub-typing relation is ormally proved with the ollowing theorem. Theorem 2. For any type T 1, T 2 T and state ρ, h, A, T 1 T 2 and ρ, h, A [T 1 ] imply ρ, h, A [T 2 ] Proo. We irst show that under the current hypotheses, or all value r and types t 1, t 2 ρ, h, A, T 1 r t 1 and t 1 σ t 2 implies ρ, h, A, T 2 r t 2 and then conclude. See the companion Coq development or details. 3.4 Type and Eect System The type system veriies, statically and class by class, that a program respects the copy policy annotations relative to a declared copy policy. The core o the type system concerns the typability o commands, which is deined through the ollowing judgment: Γ,, Θ c : Γ,, Θ. The judgment is valid i the execution o command c in a state satisying type (Γ,, Θ) will result in a state satisying (Γ,, Θ ) or will diverge. Typing rules are given in Fig. 7. We explain a selection o rules in the ollowing. The rules or i ( ) then else i, while ( ) do done, sequential composition and most o the assignment rules are standard or low-sensitive type systems. The rule or x := new allocates a resh node n with no edges in the graph and let Γ (x) reerence this node. There are two rules concerning the instruction x. :=y or assigning values to ields. I the variable x is represented by node n, then either the node is strong and we update (or add) the edge in the graph rom node n labeled to point to the value o Γ (y), or it is only weak and we must merge the previous shape with its updated version. As or method calls, two cases arise depending on whether the method is copyannotated or not. In each case we must also discuss the type o the argument y. On the one hand, i a method is associated with a copy policy τ, we compute the corresponding type (n τ, τ ) and type the result o x:=m cn:x (y) starting in (Γ,, Θ) with the result type consisting o the environment Γ where x now points to n τ, the heap described by the disjoint union o and τ, and the set o strong nodes augmented with n τ. I y is a locally allocated memory location o type n, we must remove all nodes reachable rom n, and set all its successors to. On the other hand, the method is not associated with a copy policy. I the parameter y is null or not locally allocated we know that x points to a non-locally allocated object. Else y is a locally allocated memory location o type n, and we must kill all its successors in the abstract heap. Finally, the rule or method deinition veriies the coherence o the result o analysing the body o a method m with its copy annotation Φ(τ). Type checking extends trivially to all methods o the program. Note the absence o a rule or typing an instruction x. :=y when Γ (x) = or. In a irst attempt, a sound rule would have been Γ (x) = Γ, x. :=y : Γ, [, ]

14 Command typing rules Γ,, Θ x:=y : Γ [x Γ (y)],, Θ Γ (y) = t t {, } [Γ,, Θ] x:=y. : Γ [x t],, Θ n resh in Γ,, Θ x := new cn : Γ [x n], [(n, ) ], Θ {n} Γ (x) = n Γ (y) = n Γ,, Θ x:=y. : Γ [x [n, ]],, Θ n Θ Γ,, Θ x. :=y : Γ, [n, Γ [y]], Θ Γ (x) = n n Θ (Γ, [n, Γ [y]], Θ) (Γ,, Θ ) (Γ,, Θ) (Γ,, Θ ) Γ,, Θ x. :=y : Γ,, Θ Γ,, Θ c 1 : Γ 1, 1, Θ 1 (Γ 1, 1, Θ 1) (Γ,, Θ ) Γ,, Θ c 2 : Γ 2, 2, Θ 2 (Γ 2, 2, Θ 2) (Γ,, Θ ) Γ,, Θ i ( ) then c 1 else c 2 i : Γ,, Θ Γ,, Θ c : Γ 0, 0, Θ 0 (Γ,, Θ) (Γ,, Θ ) (Γ 0, 0, Θ 0) (Γ,, Θ ) Γ,, Θ while ( ) do c done : Γ,, Θ Γ,, Θ c 1 : Γ 1, 1, Θ 1 Γ 1, 1, Θ 1 c 2 : Γ 2, 2, Θ 2 Γ,, Θ c 1; c 2 : Γ 2, 2, Θ 2 Π p(x) = τ Φ(τ) = (n τ, τ ) nodes( ) nodes( τ ) = (Γ [y] = ) (Γ [y] = ) Γ,, Θ x:=m cn:x (y) : Γ [x n τ ], τ, Θ {n τ } Π p(x) = τ Φ(τ) = (n τ, τ ) nodes( ) nodes( τ ) = KillSucc n(γ,, Θ) = (Γ,, Θ ) Γ [y] = n Γ,, Θ x:=m cn:x (y) : Γ [x n τ ], τ, Θ {n τ } (Γ [y] = ) (Γ [y] = ) Γ,, Θ x:=?(y) : Γ [x ],, Θ KillSucc n(γ,, Θ) = (Γ,, Θ ) Γ [y] = n Γ,, Θ x:=?(y) : Γ [x ],, Θ Γ,, Θ return x : Γ [ret Γ [x]],, Θ Method typing rule [ ][x ],, c : Γ,, Θ Π p(x) = τ Φ(τ) = (n τ, τ ) (Γ,, Θ) (Γ [ret n τ ], τ, {n τ }) Program typing rule Copy(X) m(x):=c cl p, md cl, md p Notations: We write [(n, ) ] or the update o with a new node n or which all successors are equal to. We write KillSucc n or the unction that removes all nodes reachable rom n (with at least one step) and sets all its successors equal to. Fig. 7: Type System

15 Because x may point to any part o the local shape we must conservatively orget all knowledge ab the ield. Moreover we should also warn the caller o the current method that a ield o his own local shape may have been updated. We choose to simply reject copy methods with such patterns. Such a strong policy has at least the merit to be easily understandable to the programmer: a copy method should only modiy locally allocated objects to be typable in our type system. For similar reasons, we reject methods that attempt to make a method call on a reerence o type because we can not track side eect modiications o such methods with loosing the modularity o the veriication mechanism. We irst establish a standard subject reduction theorem and then prove type soundness. We assume that all methods o the considered program are well-typed. Theorem 3 (Subject Reduction). Assume T 1 c : T 2 and ρ 1, h 1, A 1 [T 1 ]. I (c, ρ 1, h 1, A 1 ) ρ 2, h 2, A 2 then ρ 2, h 2, A 2 [T 2 ]. Proo. See the companion Coq development. Theorem 4. I p then all methods m declared in the program p are secure. Proo. See the companion Coq development. 1 class LinkedList<E> implements Cloneable { 2 Entry<E> header; 3 4 private static class Entry<E> { E element; Entry<E> ; Entry<E> previous; 8 } 9 public Object clone() { 11 LinkedList<E> clone = null; 12 clone = (LinkedList<E>) super.clone(); 13 clone.header = new Entry<E>; 14 clone.header. = clone.header; 15 clone.header.previous = clone.header; 16 Entry<E> e = this.header.; 17 while (e!= this.header) { 18 Entry<E> n = new Entry<E>; 19 n.element = e.element; 20 n. = clone.header; 21 n.previous = clone.header.previous; 22 n.previous. = n; 23 n..previous = n; 24 e = e.; 25 } 26 return clone; 27 } 28 } T13 T14 T16 T17 T19 T22 T22 T23 T23 T24 T24 clone clone clone clone clone clone clone clone clone clone clone header header header header prev. elem. prev. elem. prev. elem. n previous header elem. prev. prev. header header prev. prev. previous previous previous previous elem. elem. n n n header header elem. elem. header header elem. elem. n e n e n e prev. elem. e e n e elem. elem. e e Fig. 8: Intermediate Types or java.util.linkedlist.clone()

16 Example 3 (Case Study: java.util.linkedlist). In this example, we demonstrate the use o the type system on a challenging example taken rom the standard Java library. The class java.util.linkedlist provides an implementation o doubly-linked lists. A list is composed o a irst cell that points through a ield header to a collection o doubly-linked cells. Each cell has a link to the previous and the cell and also to an element o (parameterized) type E. The clone method provided in java.lang library implements a shallow copy where only cells o type E may be shared between the source and the result o the copy. In Fig. 8 we present a modiied version o the original source code: we have inlined all method calls, except those to copy methods and removed exception handling that leads to an abnormal return rom methods 5. Note that one method call in the original code was virtual and hence prevented inlining. Is has been necessary to make a private version o this method. This makes sense because such a virtual call actually constitutes a potentially dangerous hook in a cloning method, as a re-deined implementation could be called when cloning a subclass o Linkedlist. In Fig. 8 we provide several intermediate types that are necessary or typing this method (T i is the type beore executing the instruction at line i). The call to super.clone at line 12 creates a shallow copy o the header cell o the list, which contains a reerence to the original list. The original list is thus shared, a act which is represented by an edge to in type T 13. The copy method then progressively constructs a deep copy o the list, by allocating a new node (see type T 14 ) and setting all paths clone.header, clone.header. and clone.header.previous to point to this node. This is relected in the analysis by a strong update to the node representing path clone.header to obtain the type T 16 that precisely models the alias between paths clone.header, clone.header. and clone.header.previous (the Java syntax used here hides the temporary variable that is introduced to be assigned the value o clone.header and then be updated). This type T 17 is the loop invariant necessary or type checking the whole loop. It is a super-type o T 16 (updated with e ) and o T 24 which represents the memory at the end o the loop body. The body o the loop allocates a new list cell (pointed to by variable n) (see type T 19 ) and inserts it into the doubly-linked list. The assignment in line 22 updates the weak node pointed to by path n.previous and hence merges the strong node pointed to by n with the weak node pointed to by clone.header, representing the spine o the list. The assignment at line 23 does not modiy the type T 23. Notice that the types used in this example show that a low-insensitive version o the analysis could not have ound this inormation. A low-insensitive analysis would orce the merge o the types at all program points, and the call to super.clone return a type that is less precise than the types needed or the analysis o the rest o the method. 4 Inerence In order to type-check a method with the previous type system, it is necessary to iner intermediate types at each loop header and conditional junction points. A standard approach consists in turning the previous typing problem into a ixpoint problem in a suit- 5 Inlining is automatically perormed by our tool and exception control low graph is managed as standard control low but omitted here or simplicity.

17 able sup-semi-lattice structure. This section presents the lattice that we put on (T, ). Proos are generally omitted by lack o space but can be ound in the companion report. Typability is then checked by computing a suitable least-ixpoint in this lattice. We end this section by proposing a widening operator that is necessary to prevent ininite iterations. Lemma 2. The binary relation is a preorder on T. Proo. The relation is relexive because or all type T T, T id T. The relation is transitive because i there exists types T 1, T 2, T 3 T such that T 1 σ1 T 2 and T 2 σ2 T 3 or some usion maps σ 1 and σ 2 then T 1 σ3 T 3 or the usion map σ 3 deine by σ 3 (n) = σ 2 (σ 1 (n)) i σ 1 (n) N or otherwise. We write or the equivalence relation deined by T 1 T 2 i and only i T 1 T 2 and T 2 T 1. Although this entails that is a partial order structure on top o (T, ), equality and order testing remains diicult using only this deinition. Instead o considering the quotient o T with, we deine a notion o well-ormed types on which is antisymmetric. To do this, we assume that the set o nodes, variable names and ield names are countable sets and we note n i (resp. x i and i ) the ith node (resp. variable and ield). A type (Γ,, Θ) is well-ormed i every node in is reachable rom a node in Γ and the nodes in ollow a canonical numbering based on a breadth-irst traversal o the graph. Any type can be garbage-collected into a canonical well-ormed type by removing all unreachable nodes rom variables and renaming all remaining nodes using a ixed strategy based on a total ordering on variable names and ield names and a breadth-irst traversal. We note GC this transormation. The ollowing example shows the eect o GC using a canonical numbering gc 1 n 2 n n 4 n 5 n 1 x 1 x 2 x 3 x 1 x 2 x 3 Since by deinition, only deals with reachable nodes, the GC unction is a - morphism and respects type interpretation. This means than inerence engine can at any time replace a type by a garbage-collected version. This is useul to perorm an equivalence test in order to check ixpoint iteration ending. Lemma 3. For all well-ormed types T 1, T 2 T, T 1 T 2 i T 1 = T 2. Deinition 3. Let be an operator that merges two types according to the algorithm in Fig. 9. The procedure has T 1 = (Γ 1, 1, Θ 1 ) and T 2 = (Γ 2, 2, Θ 2 ) as input, then takes the ollowing steps. 1. It irst makes the disjunct union o 1 and 2 into a non-deterministic graph (NDG) α, where nodes are labelled by sets o elements in t. This operation is perormed by the lit unction, that maps nodes to singleton nodes, and ields to transitions.

18 / / I n i t i a l i z a t i o n. / / α nodes a r e s e t s i n t. / / α t r a n s i t i o n s can be / / non d e t e r m i n i s t i c. α = lit(γ 1,Γ 2, 1 2) / / S t a r t with e n v i r o n m e n t s. or {(x, t); (x, t )} (Γ 1 Γ 2) { usion({t, t }) } / / P r o p a g a t e i n α. while Field, u α, succ(u, ) > 1 { usion(succ(u,)) } / / Return t o t y p e s. (Γ,, Θ) = ground(γ 1,Γ 2,α) / / N i s a s e t o t t. / / N d e n o t e s t h e node i n α / / l a b e l l e d by t h e s e t N. void usion (N) { α α + N or t N { or Field { i u, α(t, ) = u { / / Re r o u t e bound edges. α α[( N, ) u] } i n, α(n, ) = t { / / Re r o u t e inbound edges. α α[(n, ) N ] }} α α u }} Fig. 9: Join Algorithm 2. It joins together the nodes in α reerenced by Γ i using the usion algorithm Then it scans the NDG and merges all nondeterministic successors o nodes. 4. Finally it uses the ground unction to recreate a graph rom the now-deterministic graph α. This unction operates by pushing a node set to a node labelled by the σ -sup o the set. The result environment Γ is derived rom Γ i and α beore the -reconstruction. All state usions are recorded in a map σ which binds nodes in 1 2 to nodes in. Figure 10 contains the auxiliary unctions used in the above procedure. Figure 11 unolds the algorithm on a small example. Theorem 5. The operator deines a sup-semi-lattice on types. Proo. First note that σ 1 and σ 2, the unctions associated with the two respective subtyping relations, can easily be reconstructed rom σ. Upper bound Let (T, σ) = T 1 T 2 : we prove that T 1 T and T 2 T. Hypothesis (ST 2 ) is discharged by case analysis, on t 1 and on t 2. The general argument used is that the join algorithm does not delete any edges, thus preserving all paths in the initial graphs. Least o the upper bounds Let (T, σ) = T 1 T 2. Assume there exists T such that T 1 T and T 2 T. Then we prove that T T. The proo consists in checking that the join algorithm produces, at each step, an intermediary pseudo-type T such that T T. The concrete nature o the algorithm drives the ollowing, more minute decomposition. 1. Given an unction σ, deine a state mapping unction τ, and a σ -like relation τ on non-deterministic graphs. The aim with this relation is to emulate the 6 Remark that Γ i-bindings are not represented in α, but that node set usions are trivially traceable. This allows us to saely ignore Γ i during the ollowing step and still perorm a correct graph reconstruction.

19 / / Convert a t y p e t o an NDG NDG lit (Γ 1,Γ 2, ) { NDG α = unde or x Var { α α + {Γ 1(x)} + {Γ 2(x)} } or n { i Fields, b BaseType, [n, ] = b { α α + {n} + {b} α α[( {n}, ) {b} ] }} return α } / / Convert an NDG t o a t y p e T ground (Γ 1,Γ 2,α) { Var t Γ = λx. = unde or N α { or x Var, Γ 1(x) N Γ 2(x) N { Γ Γ with Γ (x) = N }} or N, N α { i α(n, ) = N { with [c, ] = c }} return (Γ, ) } / / σ sup u n c t i o n BaseType (N) { i N { return } eli c N, c = { return } else { return reshnode() } } Fig. 10: Auxiliary join unctions x n 1 n 3 1 y n 2 n 4 y 2 x {n 1,n 3 } 3 y {n 2,n 4, } 4 x x y x y {n 1,n 3 } {n 2,n 4 } Fig. 11: An example o join

20 properties o σ, liting the partial order σ on nodes to sets o nodes (cells). Lit T into an NDG α. 2. Using the subtyping relations between T 1, T 2, and T, establish that the disjunct union and join steps produce an intermediary NDG β such that β τ α. 3. Ensure that the usions operated by the join algorithm in β produce an NDG γ such that γ τ α. This is done by case analysis, and depending on whether the usion takes place during the irst entry point processing phase, or i it occurs later. 4. Using the t-lattice, show that the ground operation on the NDG γ produces a type T that is a sub-type o T. The poset structure does not enjoy the ascending chain condition. The ollowing chain is an example ininite ascending chain. x x... x We have then to rely on a widening [7] operator to enorce termination o ixpoint computation. Here we ollow a very pragmatic approach and deine a widening operator T T T that takes the result o and that collapses together (with the operator usion deined above) any node n and its predecessors such that the minimal path reaching n and starting rom a local variable is o length at least 2. This is illustrated by the ollowing example. Widen( x x, ) = Collapse( x ) = x This ensures the initeness o the ixpoint iteration because the number o nodes is then bounded by 2N with N the number o local variables in the program. 5 Experiments The policy language and its enorcement mechanism has been implemented in the orm o a security tool or Java byte code. Standard declarations are used to speciy native annotations, which enable development environments such as Eclipse or Netbeans to parse, identiy tags. Source code annotations are being made accessible to bytecode analysis rameworks. Both the policy extraction and enorcement components are implemented using the Javalib/Sawja static analysis libraries 7 to derive annotations and intermediate code representations. In its standard mode, the tool perorms a modular veriication o annotated classes. We have run experiments on several classes o the standard library (specially in the 7

21 package java.util) and have successully checked realistic copy signatures or them (see the companion web page or examples). These experiments have also conirmed that the policy enorcement mechanism acilitates re-engineering into more compact implementations o cloning methods in classes with complex dependencies, such as those orming the gnu.xml.transorm package. For example, in the Stylesheet class an inlined implementation o multiple deep copy methods or hal a dozen ields can be rewritten to dispatch these unctionalities to the relevant classes, while retaining the expected copy policy. This is made possible by the modularity o our enorcement mechanism, which validates calls to external cloning methods as long as their respective policies have been veriied. However, some cloning methods will necessarily be beyond the reach o the analysis. We have identiied one such method in GNU Classpath s TreeMap class, where the merging o inormation at control low merge points destroys too much o the inerred type graph. A disjunctive orm o abstraction seems necessary to veriy a deep copy annotation on such programs and we leave this as a challenging extension. The analysis is also capable o processing un-annotated methods, albeit with less precision than when copy policies are available this is because it cannot rely on annotations to iner external copy method types. Nevertheless, this capability allows us to test our tool on two large code bases. The classes in Sun s rt.jar and the 7000 in the GNU Classpath have passed our scanner un-annotated. Among the 459 clone() methods we ound in these classes, only 15 have been rejected because o an illegal assignment or method call and we were unable to iner the minimal signatures {} (the same signature as java.lang.object.clone()) in 78 methods. Our prototype conirms the eiciency o the enorcement technique because all these veriications took only 25s on a laptop computer. Our prototype, the Coq ormalization and proos, as well as examples o annotated classes can be ound at 6 Related Work Several proposals or programmer-oriented annotations o Java programs have been published ollowing Bloch s initial proposal o an annotation ramework or the Java language [4]. These proposals deine the syntax o the annotations but oten leave their exact semantics unspeciied. A notable exception is the set o annotations concerning non-null annotations [8] or which a precise semantic characterization has emerged [9]. Concerning security, the GlassFish environment in Java oers program annotations o members o a class (such or implementing rolebased access control to methods. To the best o our knowledge, the current paper is the irst to propose a ormal, semantically ounded ramework or secure cloning through program annotation and static enorcement. The closest work in this area is that o Anderson et al. [2] who have designed an annotation system or C data structures in order to control sharing between threads. Annotation policies are enorced by a mix o static and run-time veriication. On the run-time veriication side, their approach requires an operator that can dynami-