1 / 34

An Information Flow Inlining Compiler for a Core of JavaScript

This work explores an Information Flow Inlining Compiler for JavaScript, addressing security concerns from dynamic code integration. It outlines a structured method to create new services by combining data and code from multiple sources while enforcing strict information flow policies. By employing techniques such as extensible objects and monitored semantics, the paper proposes solutions to prevent security leaks and ensure classified data remains confidential. A systematic analysis of potential vulnerabilities and a margin for secure execution through inlining transformations are also discussed.

georgia-knox
Télécharger la présentation

An Information Flow Inlining Compiler for a Core of JavaScript

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Web Applications Combine data and/or code from multiple origins to create a new service Are commonlyimplemented in JavaScript

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

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

  5. JavaScript Security Leaks Defining Features of JavaScript Extensible Objects Prototypical Inheritance 1 2 o1 = {}; o1.p = h; o2 = {}; o2.__proto__ = o1; o2.p o2.p leaksinformationatlevel H

  6. JavaScript Security Leaks Defining Features of JavaScript Extensible Objects Prototypical Inheritance Constructs for Checking the Existence of Properties 1 2 3 o1 = {}; if (h()) { o1.p = 1 } o1.p o1.p leaksinformationatlevel H

  7. JavaScript Security Leaks Defining Features of JavaScript Extensible Objects Prototypical Inheritance Constructs for Checking the Existence of Properties Binding of Global Variables 1 2 3 4 x = h; f = function (x) { return this.x; } l = f(0); l leaksinformationatlevelH

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

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

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

  11. Attacker Model What can an attacker see? o1 p1H: v1 p2L: v2 p2L: v2 p3L: v3 Low-Projection p3L: v3 DomainL: p1, p2, p3 DomainL: p1, p2, p3

  12. Attacker Model What can an attacker see? o1 p1H: v1 p2L: v2 p2L: v2 p3L: v3 Low-Projection p3L: v3 DomainH: p1, p2, p3

  13. Security Property When should a program P be allowed to execute? LP0 = LP0’ LP1 = LP1’ InitialMems DivergentExecutions Are Assumed NOT To LeakInformation HP0’ HP1’ LP0’ Executionof P: LP0 LP1 HP1 HP0 LP1’ Final Mems

  14. SecurityByCompilation Rewrite a program P as P’ so that: P’ only executes if the execution of P is SECURE The semantics of P’ is contained in the semantics of P 1 2

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

  16. Monitored Semantics Security Labeling = Abstract Memory Execute the Program in the: Real Memory 1 2 VariableLabeling Current Scope Object Final Value InitialMemory LeveloftheCurrentContext Final Memory Expression to Evaluate LeveloftheExpression Final VariableLabeling Final ObjectLabeling ObjectLabeling r, pc ├ <μ, Γ, Σ, e> → <μ’, Γ’, Σ’, v, σ>

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

  18. Monitored Semantics pL: l No-Sensitive Upgrades Low-Projections o1 = {}; o1.p = l; if (h()) { o1.p = 0 } o1 o1 domL: {p} domL: {p} h() Є {false, 0, null, undefined} h() Є {false, 0, null, undefined}

  19. Monitored Semantics Property Assignment: e0[e1] = e2 Evaluatesub-expressions: r, pc ├ <μ, Γ, Σ, e0> → <μ0, Γ0, Σ0, r0, σ0> r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

  20. Monitored Semantics Property Assignment Evaluatesub-expressions: r, pc ├ <μ0, Γ0, Σ0, e1> → <μ1, Γ1, Σ1, m1, σ1> r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

  21. Monitored Semantics Property Assignment Evaluatesub-expressions: r, pc ├ <μ1, Γ1, Σ1, e2> → <μ2, Γ2, Σ2, v2, σ2> r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ, Σ’, v’, σ’>

  22. Monitored Semantics Property Assignment 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) r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ’, Σ’, v’, σ’>

  23. Monitored Semantics Property Assignment e0 → r0, σ0, e1 → m1, σ1, e2 → v2, σ2 MemoryandLabelingUpdates: μ’ = μ2[(r0, m1) → σ0˅ σ1 ˅ σ2 ˅ pc ] Σ’ = Σ2[(r0, m1) → σ0˅ σ1 ˅ σ2 ˅ pc ] r, pc ├ <μ, Γ, Σ, e0[e1] = e2> → <μ’, Γ’, Σ’, v’, σ’>

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

  25. Instrumentation Pair Up Each Variable with a Shadow Variable that holds its level LabeledMemory μ, Γ, Σ InstrumentedMemory μinst • Variable: x • Value: μ(x) • Level: Γ(x) • Variable: x • ShadowVariable: levx • Value: μinst(x) • Level: μinst(levx)

  26. Instrumentation Pair Up Each Property with a Shadow Property that holds its level LabeledMemory μ, Γ, Σ InstrumentedMemory μinst • Object: o (ro) • Property: p • Value: μ(ro)(p) • Level: Σ(ro)(p) • Object: o (ro) • Property: p • ShadowProperty: levp • Value: μinst(ro)(p) • Level: μinst(ro) (levp)

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

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

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

  30. Compiler Specification Property Assignment: e0[e1] = e2 Compile SubExpressions: Comp(e0) = <e0’, x0, l0> Comp(e1) = <e1’, x1, l1> Comp(e2) = <e2’, x2, l2>

  31. 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”]) }

  32. 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

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

  34. Thank you!

More Related