A static analysis approach. Enrico Steffinlongoavp/Steffinlongo.pdfPrivilege separation in browser architectures. A static analysis approach. Enrico Steffinlongo Università Ca’

Privilege separation in browser architectures.A static analysis approach.

Enrico Steffinlongo

Universita Ca’ Foscari - Computer science

April 1, 2015

Enrico Steffinlongo Privilege separation in browser architectures. 1 / 29

Browser Extensions

Web browsers extensions are phenomenally popular.roughly 30% of Firefox users have at least one add-on

Extensions customize the user experience of the browserCustomize the user interfaceAdds lots of functionality to the browser (e.g., save andrestore tabs)Protect users from certain contents of the web pages


Browser Extensions

Extensions need to interact withWeb pages DOMBrowser API (browser storage, cookie jar, . . . )

Potential security problem!Browser API ⇒ security critical operationsWeb interaction ⇒ Untrusted and potentially malicious


Chrome extensions architecture

Chrome extension architectureforces developers to adopt threepractices

1 Privilege separation2 Least privilege3 Strong isolation


Privilege separation

Content scriptsAre injected to each page (multiple instances)Access the DOM of the pageCannot use privileges other than the one used to sendmessages to the Extension Core

Extension CoreHas a single instance for each browser sessionHas no access to DOM of pagesCan use privileges defined statically in the manifest


Least privilege

An extension has a limited set of permissions defined statically inthe manifest

An extension cannot use more than required permissionsUsers have to agree with the required permissions at installtimeAttacker cannot use more than such set of privileges


Strong isolation

All components of the extension have different address spacesexcept content scripts that can read and modify the DOM of thepage on which are injected. So an infected component cannot

alter content of variables of other componentsinvoke or alter functions defined in other components.

Communication between Extension Core and Content Scripts isonly via message passing:

Messages exchanged can only be strings (Objects aremarshaled using a JSON serializer)


Example

Content script 1:chrome . r u n t i m e . sendMessage (

{ tag : ” r e q ” , s i t e : ”www. g o o g l e . com ”} ) ;

Content script 2:chrome . r u n t i m e . sendMessage (

{ tag : ” s ync ” ,s i t e : ”www. password1 . com ”} ) ;

Attacker:chrome . r u n t i m e . sendMessage ( . . . ) ;chrome . r u n t i m e . sendMessage (

{ tag : ” r e q ” , s i t e : ”www. g o o g l e . com ”} ) ;chrome . r u n t i m e . sendMessage (

{ tag : ” s ync ” , s i t e : ”www. e v i l . com ”} ) ;

Extension Core:chrome . r u n t i m e . onMessage . a d d L i s t e n e r (

f u n c t i o n ( msg , s en d er , sendResp ) {i f ( msg . tag == ” r e q ”) {

v a r u = DB. g e t U s e r ( msg . s i t e ) ;v a r p = DB. getPwd ( msg . s i t e ) ;sendResp ({” u s e r ” : u , ”pwd ” : p} ) ;

}e l s e i f ( msg . tag == ” sy nc ”) {

v a r db = DB. s e r i a l i z e ( ) ;xm lh t tp . open (”GET” , msg . s i t e + db ) ;xm lh t tp . send ( ) ;

}e l s e

c o n s o l e . l o g (” I n v a l i d message ” ) ;} ) ;


LambdaJS (Brown university[2])

JavaScript:Complex languageLots of constructsunconventional semantics.

Very complex to analyze!

λJS [2] is a core calculus made by Brown university designedspecifically to “desugar” JavaScript

Few constructsStandard λ-style semanticsNot a sound approximation of JavaScriptTests on “desugared” files shows that its semantic coincidewith JavaScript

Easy to analyze!


The calculus (values and expressions)

λJS++ is an extension of λJS . It adds specific constructs forcommunications in privilege-separated architectures. Itscomponents are:

Constants: c ::= num | str | bool | unit | undefinedValues: v ::= n | x | c | r` | λx .e | {−−−−→stri : vi}Expressions: classical lambda calculus construct, operationson objects and on references, send and exercise

e ::= v | let x = e in e | e e | op(−→ei ) | while (e) { e }| if (e) { e } else { e } | e; e | e[e] | e[e] = e| delete e[e] | ref` e | deref e | setref e : e| e〈e . ρ〉 | exercise(ρ)

Note that both e[e] = e and delete e[e] do not modify the object,but they returns a new updated object.


The calculus (memories, handlers, instances and system)

We added to the calculus architectural components in order tomodel the extension system.

Memories: µ ::= ∅ | µ, r`ρ7→ v

Handlers: h ::= ∅ | h, a(x / ρ : ρ′).eInstances: i ::= ∅ | i , a{|e|}ρSystem: s = µ; h; i


Judgments

For the analysis we used the Flow logic [6] approach.All values are abstracted assuming a pre-order relation v.We do not fix any specific representation of the abstractdomainsAbstract environment C = Γ; µ; Υ; Φ

Each judgment of our specification has the form:C ρ v vC ρ e : v � ρ′

C µ despite ρ, C h despite ρ, C i despite ρ,C s despite ρ.


Judgment example

(PE-Cond)C ρs e0 : v0 � ρ0 v ρ

true ∈ v0 ⇒ C ρs e1 : v1 v v � ρ1 v ρfalse ∈ v0 ⇒ C ρs e2 : v2 v v � ρ2 v ρC ρs if (e0) { e1 } else { e2 } : v � ρ

(PE-App)C ρs e1 : v1 � ρ1 v ρC ρs e2 : v2 � ρ2 v ρ

∀λxρe ∈ v1. v2 v CΓ(x) ∧ CΓ(λx) v v ∧ ρe v ρC ρs e1 e2 : v � ρ


Theorem

Permission leak against ρ : Leakρ(C) is a soundover-approximation of the permissions which can be escalatedby the opponent ρ in an initial system with arbitrary long callchains.The main point of the analysis is this theorem:

Let s = µ; h; ∅.If C s despite ρ,thens is ρ′-safe despite ρ for ρ′ = Leakρ(C).

This gives us statically an over-approximation of allpermissions that an opponent can escalate to if it attacks anextension.


Implementation steps

In order to develop a tool to perform such analysis1 We turned the specification using a verbose approach that

stores all expression values in a Cache,2 The analysis of a program is turned in a finite set of

constraints,3 Starting from the set of constraints an acceptable solution is

computed.


Compositional Verbose

The translation from the Succinct approach to the Verbose one ismade adding:

1 unambiguous labels α ∈ A to each expression: e ⇒ eα;2 a Cache to the environment that stores all the partial results

of each expression: Abstract cache C : A→ V ;3 a Permission Cache to the environment that stores permissions

used by each expression: Abstract permission P : A→ ρ.


Compositional verbose

Example (if statement) in the verbose approach[CV-Cond ] CV cv ,ρs (if (e0

α0) { e1α1 } else { e2

α2 })α iffCV cv ,ρs e0

α0∧CV P(α0) v CV P(α)∧true ∈ CV C (α0)⇒CV cv ,ρs e1

α1 ∧ CV C (α1) v CV C (α)∧CV P(α1) v CV P(α)∧

false ∈ CV C (α0)⇒CV cv ,ρs e2

α2 ∧ CV C (α2) v CV C (α)∧CV P(α2) v CV P(α)


Constraint definition

Constraints have this form:

c ::= {v} v E Term inclusion| E v E Element inclusion| Op(

−→Ei ) v E Operation inclusion

| c ⇒ c Implication

Where E is an index of the environment (e.g., Γ(x)).Example: {true} v C(α) means that true is in the possibleestimate of the node marked with α.Constraints are generated from the program, and when theyare created, they can be solved without the AST.


Abstract domains

As abstract domains for pre-values we used:All finite domains are abstracted in themselves,Signs ⊕,, 0 for numbers,Prefix for strings as described by Costantini, Ferrara, Cortesiin [1],Mapping from abstract strings to abstract values for objects.

An abstract value is a set of abstract pre-value.


Solving the constraints

Constraints can be solved together with the abstract domainsdefinition using an existing fix-point constraint solver such as:

ALFP succinct solver[5];BANE constraint solver (from Berkeley university);Z3 solver (from Microsoft research)worklist algorithm described in Principle of ProgrammingAnalysis [4].

We decided to use a custom implementation of the worklistalgorithm.


Worklist algorithm

INPUT: C∗ρs J(e∗)αKOUTPUT: (C, Γ,M)METHOD:Step 1: Initialization

W := [ ] : Queue ( CElem )D := [ ] : Map( CElem −> V )E := [ ] : Map( CElem −> C o n s t r a i n t )f o r a i n cache do

Add (C a , ⊥) DAdd (C a , [ ] ) E

f o r x i n v a r s doAdd (R x , ⊥) DAdd (R x , [ ] ) E

f o r r i n r e f s doAdd (Mu (⊥ , ` ) , ⊥) DAdd (Mu (⊥ , ` ) , [ ] ) E

Step 2: Building the graphf o r cc i n l s t do

c a s e cc o f| { t} v p −>

p r o p a g a t e p { t}| p1 v p2 −>

Add cc E [ p1 ]| { t} v p ⇒ p1 v p2 −>

Add cc E [ p ]Add cc E [ p1 ]

| op(−→ps ) v p1 −>f o r p i n ps do

Add cc E [ p ]


Worklist algorithm

Step 3: Iterationw h i l e W 6= [ ] do

q = dequeue Wf o r cc i n E [ q ] do

c a s e cc o f| p1 v p2 −>

p r o p a g a t e p2 D[ p1 ]| { t} v p ⇒ p1 v p2 −>

i f t ∈ D[ p ] thenp r o p a g a t e p2 D[ p1 ]

| op(−→ps ) v p1 −>a r g s = [D[ p ] | p ∈ −→ps ]r e s = op a r g sp r o p a g a t e p1 r e s

Step 4: Recording the solutionf o r ` i n Ref∗ do µ(`) = D[Mu ` ]f o r x i n Var∗ do Γ(x) = D[ R x ]f o r α i n Cache∗ do C(α) = D[ C α ]

USING:p r o p a g a t e q d =

i f d 6v D[ q ] thenD[ q ] = D[ q ] t dEnqueue q W


Performance

We developed various version of the worklist algorithm in order toincrease the performances. We used

a generalized version of the simple worklist algorithm,a more sophisticate implementation of the constraintgenerator that joins the implication constraint with sameprecondition,an optimized version of both constraints generator and solverbased on lazy constraint generation as described in [3].

Benchmarks:

Number of nodes Base Optimized Lazy6268 8646.43 s 4171.89 s 0.94 s9111 12974.89 s 6050.89 s 6.98 s13075 29944.29 s 20334.26 s 12.21 s20134 160845.38 s 29206.74 s 136.35 s


Tool

We developed a tool written in F# to perform the analysis. In theanalysis we:

1 add the chrome API definition as prelude to each source2 desugar the source with prelude using the desugaring tool [2]3 parse the desugared file using lex/yacc4 generate the constraints for the AST5 solve the constraints using a worklist algorithm.

To increase precision of the analysis we also alpha-rename variablesand inline some functions to avoid clashing since the analysis iscontext-insensitive.


Conclusion

In this work we developed:an analysis of a Chrome extension,a tool for checking real extensions.

The tool:1 takes a real chrome extension,2 analyzes it,3 gives a static sound approximation of permissions that an

opponent can escalate to.


Future works

Automatic correction of bundled extensions in order todebundle themselves preserving their functionality.Generalization of the analysis in order to check other similararchitectures (e.g., Firefox).


Questions?


Thank you!


References

Giulia Costantini, Pietro Ferrara, and Agostino Cortesi.Static analysis of string values.In Proceedings of the 13th International Conference on Formal Methods and Software Engineering,ICFEM’11, pages 505–521, Berlin, Heidelberg, 2011. Springer-Verlag.

Arjun Guha, Claudiu Saftoiu, and Shriram Krishnamurthi.The essence of javascript.In Proceedings of the 24th European Conference on Object-oriented Programming, ECOOP’10, pages126–150, Berlin, Heidelberg, 2010. Springer-Verlag.

Simon Holm Jensen, Anders Møller, and Peter Thiemann.Interprocedural analysis with lazy propagation.In SAS, pages 320–339, 2010.

Flemming Nielson, Hanne R. Nielson, and Chris Hankin.Principles of Program Analysis.Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1999.

Flemming Nielson, Hanne Riis Nielson, Hongyan Sun, Mikael Buchholtz, Rene Rydhof Hansen, HenrikPilegaard, and Helmut Seidl.The succinct solver suite.In TACAS, pages 251–265, 2004.

Hanne Riis Nielson and Flemming Nielson.Flow logic: A multi-paradigmatic approach to static analysis.In The Essence of Computation, pages 223–244, 2002.


Documents

A static analysis approach. Enrico Steffinlongoavp/Steffinlongo.pdfPrivilege separation in browser architectures. A static analysis approach. Enrico Steffinlongo Università Ca’