An Information Flow Inlining Compiler for a

Core of JavaScript

José Fragoso SantosTamara Rezk

Equipe Project INDES

Combine data and/or code from multiple origins to create a new service

Web Applications

Are commonly implemented in JavaScript

Security Vulnerabilities

dom

Integrator.js

Gadget A Gadget B

Gadget CConfidentiality

Integrity

integrator.html

External Code

Internal script that combines the external content

Solution: Information Flow Control

JavaScript Security Leaks

Security Leaks due to:

1 Extensible Objects

address_table = {}; … register_addr = function(name, addr) { if (!address_table[name]) { address_table[name] = addr;

}}register_add(“Jose Santos”, “jose.santos@inria.fr”);

POLICY: Addresses are SECRET (H)

address_table[“Jose Santos”] leaks Information at level H

JavaScript Security Leaks

Defining Features of JavaScript

1 Extensible Objects

2 Prototypical Inheritance

o1 = {};

o1.p = h;o2 = {}; o2.__proto__ = o1;o2.p

o2.p leaks information at level H

JavaScript Security Leaks

Defining Features of JavaScript

1 Extensible Objects

2 Prototypical Inheritance

3 Constructs for Checking the Existence of Properties

o1 = {}; if (h()) { o1.p = 1} o1.p

o1.p leaks information at level H

JavaScript Security Leaks

Defining Features of JavaScript

1 Extensible Objects

2 Prototypical Inheritance

3 Constructs for Checking the Existence of Properties

4 Binding of Global Variables

x = h;f = function (x) { return this.x; }l = f(0);

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

3 Label Object Properties with Security Levels

4 Assign a Level to the Domain of Every Object

Levels

Γ : Variables → Levels

Σ : References x Property Names → Levels

Σ : 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?

Memory

Low-Proj

High-Proj

Attacker Model

What can an attacker see?

o1p1

H: v1

p2L: v2

p3L: v3

Low-Projection

DomainL: p1, p2, p3

p2L: v2

p3L: v3

DomainL: p1, p2, p3

Attacker Model

What can an attacker see?

o1p1

H: v1

p2L: v2

p3L: v3

Low-Projectionp2

L: v2

p3L: v3

DomainH: p1, p2, p3

Security Property

When should a program P be allowed to execute?

HP0LP0 HP0’LP0’

LP0 = LP0’

HP1LP1 HP1’LP1’

Initial Mems

Final Mems

Execution of P: LP1 = LP1’Divergent Executions Are Assumed

NOT To Leak Information

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 Memory

r, pc ├ <μ, Γ, Σ, e> → <μ’, Γ’, Σ’, v, σ>

Current Scope ObjectLevel of the

Current ContextInitial MemoryVariable

Labeling

Object LabelingExpression to Evaluate

Final MemoryFinal Variable Labeling

Final Object Labeling

Final ValueLevel of the Expression

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

o1 = {};o1.p = l; if (h()) { o1.p = 0}

Low-Projections

pL: l

o1

domL: {p}

h() Є {false, 0, null, undefined}

o1

domL: {p}

h() Є {false, 0, null, undefined}

Monitored Semantics

Property Assignment: e0[e1] = e2

r, pc ├ <μ, Γ, Σ, e0> → <μ0, Γ0, Σ0, r0, σ0>

r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

Evaluate sub-expressions:

Monitored Semantics

Property Assignment

r, pc ├ <μ0, Γ0, Σ0, e1> → <μ1, Γ1, Σ1, m1, σ1>

r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

Evaluate sub-expressions:

Monitored Semantics

Property Assignment

r, pc ├ <μ1, Γ1, Σ1, e2> → <μ2, Γ2, Σ2, v2, σ2>

r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

Evaluate sub-expressions:

Monitored Semantics

Property Assignment

r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ’, Σ’, v’, σ’>

e0 → r0, σ0, e1 → m1, σ1, e2 → v2, σ2

No-sensitive upgrades:

σ0 ˅ σ1 ˅ pc ≤ Σ(r0, m1) if m Є μ2(r0, dom)

σ0 ˅ σ1 ˅ pc ≤ Σ(r0, dom) if m Є μ2(r0, dom)

Monitored Semantics

Property Assignment

r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ’, Σ’, v’, σ’>

e0 → r0, σ0, e1 → m1, σ1, e2 → v2, σ2

Memory and Labeling Updates:

μ’ = μ2[(r0, m1) → σ0 ˅ σ1 ˅ σ2 ˅ pc ]

Σ’ = Σ2[(r0, m1) → σ0 ˅ σ1 ˅ σ2 ˅ pc ]

Instrumentation

Encode the labelings in the memory

Memoryμ

LabelingΓ, Σ Instrumented

Memoryμ'

S

Similarity Relation

Instrumentation

Pair Up Each Variable with a Shadow Variable that holds its level

Variable: x • Value: μ(x)• Level: Γ(x)

Labeled Memoryμ, Γ, Σ

Instrumented Memoryμinst

Variable: x Shadow Variable: levx

• Value: μinst(x)• Level: μinst(levx)

Instrumentation

Object: o (ro)Property: p • Value: μ(ro)(p)• Level: Σ(ro)(p)

Labeled Memoryμ, Γ, Σ

Instrumented Memoryμinst

Object: o (ro)Property: pShadow Property: levp • Value: μinst(ro)(p)• Level: μinst(ro) (levp)

Pair Up Each Property with a Shadow Property that holds its level

Instrumenting Objects

p: vp

q: vq

s: vs

oΣ(o)

p: σp

q: σq

s: σs

domain: σdom

S

p: vp

q: vq

s: vs

lev_p: σp

lev_q: σq

lev_dom: σdom

o’

lev_s: σs

Instrumentation

Encode the labelings in the memory

μ Γ, Σ μiS

μ' Γ’, Σ’ μi'

Monitored Execution

of P

Executionof P’

S

Comp(P) = P’

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: e0[e1] = e2

Comp(e0) = <e0’, x0, l0>

Compile SubExpressions:

Comp(e1) = <e1’, x1, l1>

Comp(e2) = <e2’, x2, l2>

Compiler Specification

Property Assignment: e0[e1] = e2

Comp(ei) = <ei’, xi, li> i = 0,1,2

Constraint: if (x1 Є dom(x0)) { check(l0 ˅ l1 ˅ pc ≤ x0[shadow(x1)]) } else { check(l0 ˅ l1 ˅ pc ≤ x0[“lev_dom”]) }

Compiler Specification

Property Assignment: e0[e1] = e2

Comp(ei) = <ei’, xi, li> i = 0,1,2

Comp(e0[e1] = e2) = e0’; e1’; e2’

Constraint x0[x1] = x2;

x0[shadow(x1)] = l0 ˅ l1 ˅ l2

Conclusions

In Summary:

1 An information flow monitor for a a core of JavaScript

2 A program transformation that inlines the monitor

3 A prototype implementation

Thank you!