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

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(ltscriptgt alert(1))
document.body.innerHTML ltscriptgt
8
JavaScript

• Things get worse

eval(alert(1))
setTimeout(alert(1), 100)
eval(alert(1))
var x wri var y te var f
documentxy f(ltscriptgt)
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 ContributionThree
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 its
  safe
• Some features not in JSGK can be avoided
  syntactically
• e.g. eval, setTimeout, setInterval,
• And some cant, 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
p?x,z
p?x,y,z
p?
q?z
q?y,z
q?
18
Flow-Insensitivity
18
q z p x p q q y
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()
p?x
p?x,z
p?x,y,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
x foo function() return new
gizmo() p x q p.foo() //returns a
gizmo q.bar()

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

22
GateKeeper Analysis
22
JavaScript AST
IR Normalizer
Output to Datalog
BDDBDDB solver
Datalog analysis rules
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 f doesnt have alert in 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 cant
  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 lt 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?
• Whats the precise overhead?
• Can widgets with forbidden features
• Be rewritten to conform?
• Proven to be safe with more advanced techniques?

30
Questions?