analysis of security critical apis · 2011-05-05 · automated encapsulation analysis of...
TRANSCRIPT
Automated EncapsulationAutomated Encapsulation Analysis of Security‐Critical APIs
Ankur TalySt f d U i itStanford University
Joint work withJ h C Mit h ll Ulf E li M k S Mill d J iJohn C. Mitchell, Ulfar Erlingsson, Mark S. Miller and Jasvir
Nagra
5/5/2011 1Stanford Security Workshop 2011
Web 2.0 – webpages with third‐party code
• Lots of client‐side JavaScript, AJAX
• High Impact: Millions of users, loads of e‐commerce, $$$.
5/5/2011 Stanford Security Workshop 2011 2
Security Issues: JavaScript is too powerful
Unrestricted DOMmanipulation
<script src=“http://adpublisher.com/ad1.js”></script>
Unrestricted DOM manipulation• top.location = http://evil.com• var c = document.getElementsByName(“cookie”)• var p = document.getElementsByName(“password”)[0]
Must sandbox untrusted code to M i l t f t f threduce its privileges ! Manipulates features of the page via the JavaScript DOM API
Escape same‐origin policy<img src=``http::www.evil.com/info.jpg?_info_”>
5/5/2011 Stanford Security Workshop 2011 3
Browser based Sandbox: IFrames.
<iframe src=“http://B.com”></iframe>Trusted Untrusted
• Like Process Isolation: Each frame has a separate execution environment
B.comA.com
A.com
B.com
environment. • Too restrictive!
• cannot communicate objects across f b dframe boundary.• Iframed ads cannot move around.
• No control over (malicious) code in f
N h h i di d i hi k !
frames.top.location = http:/evil.com
Not the mechanism studied in this work !
5/5/2011 4Stanford Security Workshop 2011
Language based Sandbox (This work)
A.com
JS Filter and Rewriter
(sandboxingA.comProtected resources
Dom Wrapper API
(sandboxing mechanism)
B.com – sandboxed JS code
B.com
F b k FBJS Y h ! ADS f G l C j
5/5/2011 Stanford Security Workshop 2011 5
Facebook FBJS, Yahoo! ADSafe, Google Caja
Approach: Security API + SandboxProtected Resources: Typically elements of the DOM.
Security API: Provide mediated access to critical resources thereby preserving a security policypreserving a security policy.
Sandbox: Restrict untrusted code idi it ONLY t th APIproviding it access ONLY to the API.
Security Goal: Untrusted code NOT b i dimust NOT obtain direct access to
any security critical resource.
Motivated by Object Capability based Security
5/5/2011 Stanford Security Workshop 2011 6
Motivated by Object‐Capability based Security.
Simple Example: Write‐only Log• Hosting page wants to provide a write onlyLog service to untrusted code.
var privLog = [<critical data>]
var api = [push: function(x){var api = [push: function(x){ privLog.push(x)}]
• Sandbox ensures that untrusted code canSandbox ensures that untrusted code can ONLY access the global variable “api”. Also all built‐ins are non‐writable.
5/5/2011 Stanford Security Workshop 2011 7
Things can go wrong very easily• Hosting page wants to provide a write onlyLog service to untrusted code..
var privLog = [<critical data>]
var api = [push: function(){var api = [push: function(){ privLog.push(x)}
store: function(i,x){privLog.store(i,x)}]
Need Automated Analysis of APIS: check for ALL possible method invocations
Is the API still safe ?
ar steal
No !!
var steal;
api.store(“push”,function()
{steal = this[0]});
5/5/2011 Stanford Security Workshop 2011 8
this[0]});
api.push();
Quick Case study: Yahoo Adsafe
• ADSAFE object (API): Provides mediated
Mechanism for safely embedding untrusted advertisements.
access to the DOM.ADSAFE.dom.fragment =
function () {reject_global(this);var frag = document createFragment()var frag = document.createFragment() return new Bunch([frag]);
}
• JSLint (Sandbox): Static filter for JSJSLint (Sandbox): Static filter for JS.• Disallows eval,this,with,o[p].• Allows untrusted code to only have a single global variable “ADSAFE”.
• Security Goal: No direct access to any DOM element.
Thi W k F d l bilit i th ADSAFE API
5/5/2011 Stanford Security Workshop 2011 9
This Work : Found a new vulnerability in the ADSAFE API.
Two Problems
S db S it P bl D iSandbox Security Problem: Design a sandbox for untrusted code that ensures that all external mutable access is derived from the API only.
API Confinement Problem: Verify that no sandboxed untrusted program can use the API to obtain direct access to a critical resource.
5/5/2011 Stanford Security Workshop 2011 10
State of JavaScript
d• ES3: JS based on ECMA‐262 3rd edition spec.
• ES5: JS based on ECMA‐262 5th edition spec (released in D 2009)Dec 2009).
• ES5S: strict mode of the ES5 language.
• SESlight: Security ECMAScript, a subset of ES5S.
– This Work !
– SES is currently under proposal by the ECMA committee.
5/5/2011 Stanford Security Workshop 2011 11
Enemies of Static Analysis in ES3
• No static scoping.
Object prototype x = 42Object prototype x = 42<some code><some code>Object.prototype.x = 42Object.prototype.x = 42
var x = 24;var f = function foo(){return x;}; f();
var x = 24;var f = function foo(){return x;}; f();
<some code><some code>
;;
What is the value returned by f() ? 42
• No Closure‐based Encapsulationpfunction trusted(untrusted, secret){if (untrusted() === secret){ <do something>}}
Can untrusted steal secret ? Yes
fTo our rescue: SESlight subset of ES5S.
untrusted = function(){steal = untrusted.caller.arguments[1]}
5/5/2011 Stanford Security Workshop 2011 12
light
Next Few Slides
• Describe the language SESlight• Describe a simple sandbox for SESlight code.g
• Describe a procedure for solving the API security problem for SESlight.
Recall: SESlight is a subset of ES5S.
5/5/2011 Stanford Security Workshop 2011 13
From ES3 to ES5S
Property: ES5S is a lexically scoped language
5/5/2011 Stanford Security Workshop 2011 14
ES5S to SESlight (Secure ECMAScript)
Sandbox Goal: Sandboxed code must derive all it external mutable access from the APImutable access from the API.
Remaining Hurdles:Remaining Hurdles:
• Default Mutable Access to all built‐in objects.Object.prototype.toString = < evil function >j p yp g
(OR Lack of Loader Isolation)
• Dynamic code execution using eval. y g
5/5/2011 Stanford Security Workshop 2011 15
ES5S to SESlight (Secure ECMAScript) • Immutable Built‐ins: No built‐in object can be mutated or extended.
• Annotated Eval:• Syntax: eval(t, x1,…,xn)• Semantic Restriction:
• Example: eval(“var x = y + z” ”y” ”z”) terminates• Example: eval( var x = y + z , y , z ) terminates normally but eval(“var x = y + z”,”y”) throwsTypeError.
• No Setters/Getters: Removed purely for ease of analysis (will be there in next paper !)be there in next paper !)
5/5/2011 Stanford Security Workshop 2011 16
Simple Sandbox for SESlight
Trusted hosting Sandboxed untrusted code
Write Readvar api
• Trusted page code creates an API object and stores it in the variable “api”
page code untrusted code.p
variable api .• Sandbox:
– Only accessible trusted code global variable must be “api”.– Also provide a variable “test” as a challenge variableAlso provide a variable test as a challenge variable.– Untrusted code wins if it sets “test” to a critical object.
Sandbox: Rewrite untrusted code s to eval(s,”api”,”test”)
• Much simpler than JSLint, FBJS, Caja• Thanks to the cleaner ES5S semantics !
5/5/2011 Stanford Security Workshop 2011 17
Formulating the API Confinement Problem
Trusted Code t
Sandboxed Untrusted Codeeval(s,“api”,”test”);t eval(s, api , test )
PointsTo(x, t): Set of values that get stored in variable x during th ti f t
;
Only involves analysis of trusted code, assuming the execution of program t.
Confine(Confine(t P): For all programs s in SESli h
y y , gworst case for untrusted code.
Confine(t, P): For all programs s in SESlight, PointsTo(“test”, t ; eval(s,“api”,”test”)) does not contain any reference from the set P.
API Security Problem: Given trusted code t and a set of critical f P if C fi (t P)
5/5/2011 Stanford Security Workshop 2011 18
references P, verify Confine(t,P)
S l i h API S i P blSolving the API Security Problem
5/5/2011 Stanford Security Workshop 2011 19
Technique
• Points‐to Analysis– Context Insensitive: Single Activation Record per function.g p
– Flow Insensitive: Insensitive to the order of statements.
• Only track references, ignore primitive values.
• Expressed in Datalog (Whaley et al)– Collect Facts about the program: Assign(x,y), Load(x,y,z),...– Encode semantics of the program as Horn clauses:p g
Stack(x,l) :- Assign(x,y), Stack(y,l)– Generate all possible consequence facts under the rules.
Tricky Case: eval capturing implicit code execution– Tricky Case: eval, capturing implicit code execution.– Scalable and well studied technique for C, Java.
5/5/2011 Stanford Security Workshop 2011 20
Simple Example
Program t:
var y = {};
Facts:
Stack(y,ly)y {};
var z = {};
var x = y;
y, y
Stack(z,lz)
Assign(x,y)
( )
encode
x.f = z;
x = y.f;
Store(x,”f”,z)
Load(x,y,”f”)
Consequence Facts: Stack(y l ) Stack(z l ) Stack(x l )Stack(y,ly), Stack(z,lz), Stack(x,ly), Stack(x,lz), Heap(ly,”f”, lz)
P i t t ( t) {l l }
5/5/2011 Stanford Security Workshop 2011 21
Pointsto(x, t) = {ly,lz }
Datalog Predicates
5/5/2011 Stanford Security Workshop 2011 22
Encoding Eval
5/5/2011 Stanford Security Workshop 2011 23
Inference Rules
5/5/2011 Stanford Security Workshop 2011 24
ProcedureProcedure D(t, P):Procedure D(t, P):
1. Pick any s in SESlight and set tnew t; eval(s, “api”, “test”)1. Pick any s in SESlight and set tnew t; eval(s, api , test )
2. D1 Encode(tnew) + Encoding of built‐in objects.
3. D2 All possible consequences of D1
4. Return CONFINED iff there is NO l P such that
Stack(“test”,l) D2
Theorem: Procedure D(t,P) is SOUNDIf the procedure says CONFINED then the API is actually safe.
P O kl d’ 11
5/5/2011 Stanford Security Workshop 2011 25
Paper at Oakland’ 11
ApplicationsApplications
ENCAP: http://code.google.com/p/es‐lab/trunk/src/util/EncapsulationAnalysis
1. Yahoo! ADSafe DOM API – This talk2. Mark Miller’s Mint Library – see paper3 Sealers and Unsealers Library – see paper3. Sealers and Unsealers Library see paper
5/5/2011 Stanford Security Workshop 2011 26
Yahoo! ADSafe
• ADSafe API does not use setters/getters• ADSafe API does not use setters/getters
• can be de‐sugared to SESlight• Added Annotations on Property lookups:Added Annotations on Property lookups:
• $NotReject: Added to patterns of the formif(!reject(name)){ …object[name, $NotReject]…}
• Approx 2000 LOC.
On Running ENCAP: We obtained the result NOT CONFINED if the methods ADSAFE.lib and ADSAFE.go were exposed to untrusted code.
5/5/2011 Stanford Security Workshop 2011 27
This turned out to be a real Attack !
Add Add “___nodes__” property toadsafe_libproperty to adsafe_lib
• ADSafe API protects DOM objects by hiding them behind “___nodes___” property of certain fake object (Bunch objects).
• Assumption: Sandboxed code can never write to “___nodes___” property of any object.
Pass adsafe_lib Pass adsafe_lib as Bunch
bj DOM
5/5/2011 Stanford Security Workshop 2011 28
object to DOM wrapper
Fixing the Attack
• Replace ADSafe.lib with the following{ADSafe.lib = function(name, f){
if(!reject_name(name){adsafe lib[name] =
f(adsafe_lib)}}
On running ENCAP: We obtain that the API is CONFINEDOn running ENCAP: We obtain that the API is CONFINED.
ADSafe API is confined under the provided annotations and the SESlight threat model.
Currently adopted by ADSafe
5/5/2011 Stanford Security Workshop 2011 29
Currently adopted by ADSafe.
Summary
• SESlight is more amenable to static analysis than ES3light y
• Confinement analysis only involves analyzing trusted code.
• Precision can be improved by further restricting• Precision can be improved by further restricting (trusted) developers to a more static analysis‐friendly subset.
5/5/2011 Stanford Security Workshop 2011 30
Future Work
• Setters/Getters
• Improving Context‐sensitivity of the analysisImproving Context sensitivity of the analysis• Explore CFA2, Object‐sensitivity.
• Provenance tracking in Datalog• Provenance tracking in Datalog.
• Multiple untrusted components instead of one.
Collusion between components can be a problem–Collusion between components can be a problem.
5/5/2011 Stanford Security Workshop 2011 31
Thank You
5/5/2011 Stanford Security Workshop 2011 32
Operational Semantics of SESlight• Small step style Operational Semantics.
• Describes intermediate execution statesDescribes intermediate execution states.• Based on ECMA262 5th edition spec.
• Key differences with ES3 semantics.y• Activation record modeled as store data‐structure instead of scope objects.• Simpler and more standard rules for most constructs.• 20 pages instead of 70 !0 pages instead of 70 !
Properties:• Free variables can be statically defined.• A term derives all its external mutable access from its free variables.
5/5/2011 Stanford Security Workshop 2011 33
Previous Work (with S. Maffeis, J. Mitchell)
• Operational Semantics for ES3 (APLAS’08)
• Secure subsets of ES3 (CSF’00, W2SP’09, ESORICS’09)Secure subsets of ES3 (CSF 00, W2SP 09, ESORICS 09)• Subset Jsafe(B) for a blacklist B of property names.
• An enforcement function enf: Jsafe(B) ‐> Jsafe(B) based on
filtering, rewriting and wrapping of code.
Theorem: For all programs t in Jsafe(B), enf(t) never accesses a fblack‐listed property names and never obtains direct access to the global object.
• Sandbox Security Problem can be solved for ES3.• API Security Problem still remains unsolved for ES3
• static analysis of ES3 is challenging !
5/5/2011 Stanford Security Workshop 2011 34
static analysis of ES3 is challenging !