An Information Flow Inlining Compiler for a Core

An Information Flow Inlining Compiler for a Core of Java. Script José Fragoso Santos Tamara Rezk Equipe Project INDES

Web Applications Combine data and/or code from multiple origins to create a new service Are commonly implemented in Java. Script

Security Vulnerabilities Internal script that combines the external content integrator. html dom Integrity Integrator. js External Code Solution: Information Flow Control Gadget A Confidentiality Gadget B Gadget C

Java. Script Security Leaks due to: POLICY: Addresses are SECRET (H) 1 Extensible Objects address_table = {}; … register_addr = function(name, addr) { if (!address_table[name]) { address_table[name] = addr; }} address_table[“Jose leaks register_add(“Jose Santos”, Santos”] “jose. santos@inria. fr”); Information at level H

Java. Script Security Leaks Defining Features of Java. Script o 1 = {}; 1 Extensible Objects o 1. p = h; Prototypical Inheritance 2 o 2 = {}; o 2. __proto__ = o 1; o 2. p leaks information at level H

Java. Script Security Leaks Defining Features of Java. Script o 1 = {}; if (h()) { o 1. p = 1 } o 1. p leaks information at level H 1 Extensible Objects 2 Prototypical Inheritance 3 Constructs for Checking the Existence of Properties

Java. Script Security Leaks Defining Features of Java. Script x = h; f = function (x) { return this. x; } l = f(0); 1 Extensible Objects 2 Prototypical Inheritance 3 Constructs for Checking the Existence of Properties 4 Binding of Global Variables l leaks information at level H

Information Flow Control Public Outputs Should NOT Depend on Secret Inputs 1 Establish a Lattice of Security Levels 2 Label Variables with Security Levels Γ : Variables → Levels 3 Label Object Properties with Security Levels 4 Σ : References x Property Names → Levels Assign a Level to the Domain of Every Object Σ : References → Levels

Attacker Model What can an attacker see? 1 Values of variables labeled with L 2 Values of properties labeled with L 3 The domains of the objects labeled with L

Attacker Model What can an attacker see? Low-Proj Memory High-Proj

Attacker Model What can an attacker see? p 1 H: v 1 p 2 L : v 2 p 3 L : v 3 Domain. L: p 1, p 2, p 3 o 1 Low-Projection p 2 L : v 2 p 3 L : v 3 Domain. L: p 1, p 2, p 3

Attacker Model What can an attacker see? p 1 H: v 1 p 2 L : v 2 p 3 L : v 3 Domain. H: p 1, p 2, p 3 o 1 Low-Projection p 2 L : v 2 p 3 L : v 3

Security Property When should a program P be allowed to execute? LP 0 = LP 0’ Initial Mems HP 0 LP 0’ HP 0’ Divergent Executions Are Assumed LP = LP 1 1’ Execution of P: NOT To Leak Information HP 1 Final Mems LP 1’ HP 1’

Security By Compilation Rewrite a program P as P’ so that: 1 P’ only executes if the execution of P is SECURE 2 The semantics of P’ is contained in the semantics of P

Security By Compilation A Recipe for Designing Inlining Transformations: 1 Specify a Monitored Semantics 2 Prove the Monitored Semantics Secure 3 Specify a Program Transformation that Inlines the Monitor 4 Prove the Inlining Transformation Correct

Monitored Semantics Execute the Program in the: 1 Real Memory 2 Security Labeling = Abstract. Final Memory Object Level of the Object Labeling Initial Memory Final Variable Final Value Current Scope Expression to Variable Level of the Final Memory Labeling Current Labeling Expression Object Context Evaluate Labeling r, pc ├ <μ, Γ, Σ, e> → <μ’, Γ’, Σ’, v, σ>

Monitored Semantics No-Sensitive Upgrades Idea: • Visible Resources cannot be updated in invisible contexts High Executions do NOT change the low projection of the memory

Monitored Semantics No-Sensitive Upgrades o 1 = {}; o 1. p = l; if (h()) { o 1. p = 0 } Low-Projections o 1 p. L : l dom. L: {p} h() Є {false, 0, null, undefined}

Monitored Semantics Property Assignment: e 0[e 1] = e 2 Evaluate sub-expressions: r, pc ├ <μ, Γ, Σ, e 0> → <μ 0, Γ 0, Σ 0, r 0, σ0> r, pc ├ <μ, Γ, Σ, e 0[e 1] = e 2> → <μ’, Γ, Σ’, v’, σ’>

Monitored Semantics Property Assignment Evaluate sub-expressions: r, pc ├ <μ 0, Γ 0, Σ 0, e 1> → <μ 1, Γ 1, Σ 1, m 1, σ1> r, pc ├ <μ, Γ, Σ, e 0[e 1] = e 2> → <μ’, Γ, Σ’, v’, σ’>

Monitored Semantics Property Assignment Evaluate sub-expressions: r, pc ├ <μ 1, Γ 1, Σ 1, e 2> → <μ 2, Γ 2, Σ 2, v 2, σ2> r, pc ├ <μ, Γ, Σ, e 0[e 1] = e 2> → <μ’, Γ, Σ’, v’, σ’>

Monitored Semantics Property Assignment e 0 → r 0, σ 0 , e 1 → m 1, σ 1 , e 2 → v 2, σ 2 No-sensitive upgrades: σ0 ˅ σ1 ˅ pc ≤ Σ(r 0, m 1) if m Є μ 2(r 0, dom) σ0 ˅ σ1 ˅ pc ≤ Σ(r 0, dom) if m Є μ 2(r 0, dom) r, pc ├ <μ, Γ, Σ, e 0[e 1] = e 2> → <μ’, Γ’, Σ’, v’, σ’>

Monitored Semantics Property Assignment e 0 → r 0, σ 0 , e 1 → m 1, σ 1 , e 2 → v 2, σ 2 Memory and Labeling Updates: μ’ = μ 2[(r 0, m 1) → σ0 ˅ σ1 ˅ σ2 ˅ pc ] Σ’ = Σ 2[(r 0, m 1) → σ0 ˅ σ1 ˅ σ2 ˅ pc ] r, pc ├ <μ, Γ, Σ, e 0[e 1] = e 2> → <μ’, Γ’, Σ’, v’, σ’>

Instrumentation Encode the labelings in the memory Similarity Relation S Memory μ Labeling Γ, Σ Instrumented Memory μ'

Instrumentation Pair Up Each Variable with a Shadow Variable that holds its level Labeled Memory μ, Γ, Σ Variable: x • Value: μ(x) • Level: Γ(x) Instrumented Memory μinst Variable: x Shadow Variable: levx • Value: μinst(x) • Level: μinst(levx)

Instrumentation Pair Up Each Property with a Shadow Property that holds its level Labeled Memory μ, Γ, Σ Instrumented Memory μinst Object: o (ro) Property: p • Value: μ(ro)(p) • Level: Σ(ro)(p) Object: o (ro) Property: p Shadow Property: levp • Value: μinst(ro)(p) • Level: μinst(ro) (levp)

Instrumenting Objects p: vp q: vq s: vs o p: σp p: vp lev_p: σp q: σq q: vq lev_q: σq s: σs s: vs lev_s: σs domain: σdom Σ(o) S lev_dom: σdom o’

Instrumentation Encode the labelings Comp(P)in=the P’ memory μ Γ, Σ Monitored Execution of P μ' S μi Execution of P’ Γ’, Σ’ S μ i'

Compiler Specification Comp(e) = <e’, x, l> 1 e’ simulates the execution of e in the monitored semantics 2 x bookkeeps the value to which e evaluates 3 l bookkeeps the level of e

Compiler Specification Property Assignment: e 0[e 1] = e 2 Compile Sub. Expressions: Comp(e 0) = <e 0’, x 0, l 0> Comp(e 1) = <e 1’, x 1, l 1> Comp(e 2) = <e 2’, x 2, l 2>

Compiler Specification Property Assignment: e 0[e 1] = e 2 Comp(ei) = <ei’, xi, li> i = 0, 1, 2 Constraint: if (x 1 Є dom(x 0)) { check(l 0 ˅ l 1 ˅ pc ≤ x 0[shadow(x 1)]) } else { check(l 0 ˅ l 1 ˅ pc ≤ x 0[“lev_dom”]) }

Compiler Specification Property Assignment: e 0[e 1] = e 2 Comp(ei) = <ei’, xi, li> i = 0, 1, 2 Comp(e 0[e 1] = e 2) = e 0’; e 1’; e 2’ Constraint x 0[x 1] = x 2; x 0[shadow(x 1)] = l 0 ˅ l 1 ˅ l 2

Conclusions In Summary: 1 An information flow monitor for a a core of Java. Script 2 A program transformation that inlines the monitor 3 A prototype implementation

Thank you!