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”, “[email protected]”);
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!
Top Related