Download presentation
Presentation is loading. Please wait.
Published byIsabel Petitt Modified over 10 years ago
1
GATEKEEPER MOSTLY 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 2
3
JavaScript Widgets 3
4
Hosted by widget hosts iGoogle Microsoft Live.com (“Web Gadgets”) Windows Sidebar (“Desktop Gadgets”) Execute in client browser Trusts the widget host Written by 3 rd party developers Untrusted! 4
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 5
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 6 Illustration from Guarnieri & Livshits
7
JavaScript Modest goal Make sure alert() is never called What do calls to alert() look like? 7 document.write(“ … alert(1)…”); alert.apply(global,[1]) alert(1); document.body.innerHTML = “ …” var f = alert; f(1);
8
JavaScript Things get worse 8 eval(“al”+“ert(1)”); var x = “wri”; var y = “te”; var f = document[x+y]; f(“ …”); eval(“alert(1)”); setTimeout(“alert(1)”, 100);
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 9
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 10
11
What do people use? 11
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” 12
13
GateKeeper language subsets 13
14
GateKeeper language subsets 14 JavaScript SAFE can be analyzed statically With reasonable precision JavaScript GK includes common features not in JS SAFE Often used safely Can rewrite each use to dynamically check if it’s safe Some features not in JS GK can be avoided syntactically e.g. eval, setTimeout, setInterval, … And some can’t, e.g. document.write()
15
GateKeeper Architecture 15 Illustration from Guarnieri & Livshits
16
Short Aside: Points-to Analysis 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 16 var a = document; var b = a.write; b(“…”); if (user_input) p = q; else p = r;
17
Points-to Analysis 17 q {z} p {x}p {x,z} q {y,z} p {x,y,z} p= q= 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)
18
q = z; p = x; p = q; q = y; Flow-Insensitivity 18 q {z} p {x}p {x,z} q {y,z} p {x,y,z} p= q= 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();
19
Short Aside: Datalog A restricted subset of Prolog Expressive enough for our needs Facts and rules Facts: Rules: Queries: 19 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 Translate assignments to facts And analysis to rules Apply rules until a fixed point is reached 20 p = new object()PtsTo(p,o 1 ) p = qAssign(p,q) PtsTo(p,o) :- PtsTo(q,o), Assign(p,q)
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() Call-Graph construction 21 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 BDDBDDB solver Analysis Results Datalog analysis rules Illustration from Guarnieri & Livshits
23
Instrumentation Can not just forbid some features 75% of Live.com widgets write to innerHTML Normally write “regular” HTML Not scripts Add runtime checks 23 if(toStaticHTML(v2) === v2)) v1.innerHTML = v2; else alert(“…”);
24
Policies Restrict function calls The alert() example we saw Points-to analysis is a “may” analysis If f doesn’t have alert in its points-to set We know for sure f () is not an alert () call. Cheating a bit… What about document.write()? 24
25
Policies Avoid document.write() Most sources of code injection are not part of JS SAFE No way to avoid document.write() syntactically Crucial for soundness of the analysis A special case of the previous policy! 25 var a = document; var b = a.write; b(“…”);
26
Policies 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 26
27
Experimental Results Examined 8379 widgets 38% JavaScript SAFE 40% JavaScript GK 22% Could not be analyzed 27
28
Experimental Results 1341 real policy violations In 684 widgets Verified by hand! 113 false positives In only 2 widgets! Analysis run time < 4 seconds 28
29
Summary Sound and very precise For widgets it can handle Only ~38% are in JavaScript SAFE 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? 29
30
Questions? 30
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.