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