GATEKEEPER

MOSTLY STATIC ENFORCEMENT OF SECURITY AND RELIABILITY PROPERTIES

FOR JAVASCRIPT CODE

Salvatore Guarnieri & Benjamin LivshitsPresented by Michael Kuperstein

Outline

Motivation

JavaScript Why is it hard?

GateKeeper Analysis Policies Experimental Results

2

JavaScript Widgets3

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!

4

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

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

JavaScript

Modest goal Make sure alert() is never called What do calls to alert() look like?

7

document.write(“<script> … alert(1)…”);

alert.apply(global,[1])

alert(1);

document.body.innerHTML = “<script>…”

var f = alert;f(1);

JavaScript

Things get worse

8

eval(“al”+“ert(1)”);

var x = “wri”;var y = “te”;var f = document[x+y];f(“<script>…”);

eval(“alert(1)”);

setTimeout(“alert(1)”, 100);

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

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

What do people use?11

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

GateKeeper language subsets

13

GateKeeper language subsets

14

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()

GateKeeper Architecture15

Illustration from Guarnieri & Livshits

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;

Points-to Analysis17

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)

q = z; p = x; p = q; q = y;

Flow-Insensitivity18

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();

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) ?

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,o1)

p = q Assign(p,q)

PtsTo(p,o) :- PtsTo(q,o), Assign(p,q)

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 construction21

x = {‘foo’ : function() { return new gizmo() }};

p = x;q = p.foo(); //returns a gizmoq.bar();

GateKeeper Analysis22

JavaScript AST

JavaScript AST

IR Normaliz

er

IR Normaliz

er

Output to Datalog

Output to Datalog

BDDBDDB solver

Analysis ResultsAnalysis Results

Datalog analysis

rules

Datalog analysis

rules

Illustration from Guarnieri & Livshits

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(“…”);

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

Policies

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!

25

var a = document;var b = a.write;b(“…”);

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

Experimental Results

Examined 8379 widgets 38% JavaScriptSAFE

40% JavaScriptGK

22% Could not be analyzed

27

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

Summary

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?

29

Questions?30