1 / 30

GATEKEEPER MOSTLY STATIC ENFORCEMENT OF SECURITY AND RELIABILITY PROPERTIES FOR JAVASCRIPT CODE

GATEKEEPER MOSTLY STATIC ENFORCEMENT OF SECURITY AND RELIABILITY PROPERTIES FOR JAVASCRIPT CODE. Salvatore Guarnieri & Benjamin Livshits Presented by Michael Kuperstein. Outline. Motivation JavaScript Why is it hard? GateKeeper Analysis Policies Experimental Results.

pleasance-roche
Download Presentation

GATEKEEPER MOSTLY STATIC ENFORCEMENT OF SECURITY AND RELIABILITY PROPERTIES FOR JAVASCRIPT CODE

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. GATEKEEPERMOSTLY STATIC ENFORCEMENT OF SECURITY AND RELIABILITY PROPERTIES FOR JAVASCRIPT CODE Salvatore Guarnieri & Benjamin Livshits Presented by Michael Kuperstein

  2. Outline • Motivation • JavaScript • Why is it hard? • GateKeeper • Analysis • Policies • Experimental Results

  3. JavaScript Widgets

  4. JavaScript Widgets • Hosted by widget hosts • iGoogle • Microsoft • Live.com (“Web Gadgets”) • Windows Sidebar (“Desktop Gadgets”) • Execute in client browser • Trusts the widget host • Written by 3rd party developers • Untrusted!

  5. Security Implications • Widgets may have security vulnerabilities • Execute in the context of the hosting site • Remember last week? • Malicious widgets • Directly harm the clients • Use the widget host to distribute malicious code

  6. Solution? • Statically analyze submitted widgets • Host performs analysis • Reject offending widgets • Reject if they violate some predefined policies • Give feedback to the widget writer Illustration from Guarnieri & Livshits

  7. JavaScript • Modest goal • Make sure alert() is never called • What do calls to alert() look like? alert(1); var f = alert; f(1); alert.apply(global,[1]) document.write(“<script> … alert(1)…”); document.body.innerHTML = “<script>…”

  8. JavaScript • Things get worse eval(“alert(1)”); setTimeout(“alert(1)”, 100); eval(“al”+“ert(1)”); var x = “wri”; var y = “te”; var f = document[x+y]; f(“<script>…”);

  9. Static Analysis? • Code is built dynamically • “Wild” reflection • Even creating a call graph is very hard • To make analysis feasible • Get rid of some “too dynamic” features • Statically analyze the rest

  10. Security Dilemma • Want to forbid problematic language features • Which? • Too liberal: • Vulnerabilities may still exist • Example: Facebook • Too conservative: • Can prove there are no vulnerabilities (soundness) • Language becomes useless, nobody writes widgets • Example: ADSafe

  11. What do people use?

  12. GateKeeper Main Contribution:Three tiered-approach • Allow “safe” features • Can be analyzed statically • Forbid “very dangerous” features • Very hard to analyze statically • Dynamically check “dangerous but useful”

  13. GateKeeper language subsets

  14. GateKeeper language subsets • JavaScriptSAFE can be analyzed statically • With reasonable precision • JavaScriptGK includes common features not in JSSAFE • Often used safely • Can rewrite each use to dynamically check if it’s safe • Some features not in JSGK can be avoided syntactically • e.g. eval, setTimeout, setInterval, … • And some can’t, e.g. document.write()

  15. GateKeeper Architecture Illustration from Guarnieri & Livshits

  16. Short Aside: Points-to Analysis 16 • How do we know what gets called? • Points-To Analysis • Figure out what object a variable points to • Often impossible to precisely know statically • “May” analysis var a = document; var b = a.write; b(“…”); if (user_input) p = q; else p = r;

  17. Points-to Analysis 17 x = new gizmo(); y = new gadget(); z = new fnord(); q = z; do { if (user_input) p = x; else p = q; if (more_user_input) q = y; } while(something_holds) p{x,y,z} p{x} p{x,z} p= q{z} q{y,z} q=

  18. Flow-Insensitivity 18 q = z; do { if (user_input) p = x; else p = q; if (more_user_input) q = y; } while(something_holds) x = new gizmo(); y = new gadget(); z = new fnord(); q = z; p = x; p = q; q = y; p{x,y,z} p{x} p{x,z} p= q{z} q{y,z} q=

  19. Short Aside: Datalog 19 • A restricted subset of Prolog • Expressive enough for our needs • Facts and rules • Facts: • Rules: • Queries: PARENT(Abraham, Isaac), PARENT(Isaac, Jacob) ANCESTOR(X,Y) :- PARENT(X,Y) ANCESTOR(X,Z) :- PARENT(X,Y), ANCESTOR(Y,Z) ANCESTOR(Abraham, Jacob) ?

  20. Points-To Analysis Using Datalog 20 • Translate assignments to facts • And analysis to rules • Apply rules until a fixed point is reached p = new object() PtsTo(p,o1) p = q Assign(p,q) PtsTo(p,o) :- PtsTo(q,o), Assign(p,q)

  21. Call-Graph construction 21 • Find out what p points to • Once we know p points to a gizmo • We know the type of q (by analyzing foo() ) • Can resolve the call to bar() • And maybe gizmo.bar() calls alert() x = {‘foo’ : function() { return new gizmo() }}; p = x; q = p.foo(); //returns a gizmo q.bar();

  22. GateKeeper Analysis 22 JavaScript AST IR Normalizer Output to Datalog Datalog analysis rules BDDBDDB solver Analysis Results Illustration from Guarnieri & Livshits

  23. Instrumentation 23 • Can not just forbid some features • 75% of Live.com widgets write to innerHTML • Normally write “regular” HTML • Not scripts • Add runtime checks if(toStaticHTML(v2) === v2)) v1.innerHTML = v2; else alert(“…”);

  24. Policies 24 • Restrict function calls • The alert() example we saw • Points-to analysis is a “may” analysis • If fdoesn’t have alertin its points-to set • We know for sure f() is not an alert()call. • Cheating a bit… • What about document.write()?

  25. Policies 25 • Avoid document.write() • Most sources of code injection are not part of JSSAFE • No way to avoid document.write() syntactically • Crucial for soundness of the analysis • A special case of the previous policy! var a = document; var b = a.write; b(“…”);

  26. Policies 26 • Most other implemented policies were similar • Avoid window.open() • Avoid calls on XMLHttpRequest objects • Avoid redirection • Boils down to avoiding writing to “location” fields • This is the type of policy we usually want • As long as the widget is self-contained, it can’t do much damage

  27. Experimental Results 27 • Examined 8379 widgets • 38% JavaScriptSAFE • 40% JavaScriptGK • 22% Could not be analyzed

  28. Experimental Results 28 • 1341 real policy violations • In 684 widgets • Verified by hand! • 113 false positives • In only 2 widgets! • Analysis run time < 4 seconds

  29. Summary 29 • Sound and very precise • For widgets it can handle • Only ~38% are in JavaScriptSAFE • Not clear what the impact of instrumentation is • Do the dynamic checks usually pass? Fail? • What’s the precise overhead? • Can widgets with forbidden features: • Be rewritten to conform? • Proven to be safe with more advanced techniques?

  30. Questions?

More Related