Department of Electrical Engineering and Computer Science CONSCRIPT

  • Slides: 32
Download presentation
Department of Electrical Engineering and Computer Science CONSCRIPT: Specifying and Enforcing Fine-Grained Security Policies

Department of Electrical Engineering and Computer Science CONSCRIPT: Specifying and Enforcing Fine-Grained Security Policies for Java. Script in the Browser Leo A. Meyerovich and Benjamin Livshits Presented by Josiah Matlack and Maciek Swiech

Department of Electrical Engineering and Computer Science Background and Motivation • Webpages are a

Department of Electrical Engineering and Computer Science Background and Motivation • Webpages are a “mashup” of Javascript – on the page and in external files • Inclusion of third party content is necessary, but untrusted • Many policies and enforcement mechanisms • Granularity, performance, and correctness • CONSCRIPT is high performance, low complexity • Example: eval • • Necessary evil (for JSON data) window. eval = function() { // safe code } Hiding is insufficient Use Con. Script to advise the calls

Department of Electrical Engineering and Computer Science Background and Motivation • Simple (shallow) aspect

Department of Electrical Engineering and Computer Science Background and Motivation • Simple (shallow) aspect systems unable to detect all attacks • Difficult (at best) to prove correctness • Foiled by various prototyping attacks • Not only Java. Script but native elements must be protected and validated • Browser functionality provided by document and window

Department of Electrical Engineering and Computer Science Background and Motivation • Aspect-oriented systems •

Department of Electrical Engineering and Computer Science Background and Motivation • Aspect-oriented systems • Breakdown logic into concerns • Cohesive area of functionality • Grouping and encapsulation of concerns • Cross-cutting concerns • Cut across multiple abstractions • Alter behavior through advice and pointcuts • Aspects: code (and included advice) • Pointcut: specified moment of execution

Department of Electrical Engineering and Computer Science Aspect-Oriented Programming (AOP) • Complementary to OOP

Department of Electrical Engineering and Computer Science Aspect-Oriented Programming (AOP) • Complementary to OOP model, allows for simplification of code • Cross-cutting concerns: secondary functionality that may be replicated across various classes / primary functionalities • Advice: additional code to be applied to the model • Point-cut: a point of application execution at which crosscutting needs to be applied • Aspect: the combination of the point-cut and advice

Department of Electrical Engineering and Computer Science AOP Example void transfer(Account from. Acc, Account

Department of Electrical Engineering and Computer Science AOP Example void transfer(Account from. Acc, Account to. Acc, int amount) throws Exception { if (from. Acc. get. Balance() < amount) { throw new Insufficient. Funds. Exception(); } from. Acc. withdraw(amount); to. Acc. deposit(amount); } Security? ?

Department of Electrical Engineering and Computer Science AOP Example (cont. ) void transfer(Account from.

Department of Electrical Engineering and Computer Science AOP Example (cont. ) void transfer(Account from. Acc, Account to. Acc, int amount, User user, Logger logger) throws Exception { logger. info("Transferring money. . . "); if (! check. User. Permission(user)){ logger. info("User has no permission. "); throw new Unauthorized. User. Exception(); } if (from. Acc. get. Balance() < amount) { logger. info("Insufficient funds. "); throw new Insufficient. Funds. Exception(); } Now we have checks… from. Acc. withdraw(amount); to. Acc. deposit(amount); logger. info("Successful transaction. "); } What if security concerns change?

Department of Electrical Engineering and Computer Science AOP Example (cont. ) • External interests

Department of Electrical Engineering and Computer Science AOP Example (cont. ) • External interests (security checks, logging) have become tangled with the main interest of the application • Aspects can contain advice – code that is joined to specific parts of a program • Contain cross-cutting code in a central and easy to manage / reason about place

Department of Electrical Engineering and Computer Science AOP Example (cont. ) aspect Logger {

Department of Electrical Engineering and Computer Science AOP Example (cont. ) aspect Logger { void Bank. transfer(Account from. Acc, Account to. Acc, int amount, User user, Logger logger) { logger. info("Transferring money. . . "); } void Bank. get. Money. Back(User user, int transaction. Id, Logger logger) { logger. info("User requested money back. "); } // other crosscutting code. . . }

Department of Electrical Engineering and Computer Science Basic Problem • Create a browser-based aspect

Department of Electrical Engineering and Computer Science Basic Problem • Create a browser-based aspect system that constrains the Java. Script code that can run on a webpage by specifying security policies • Allow policies to be set by the webpage

Department of Electrical Engineering and Computer Science Basic Problem (cont. ) • Browser aspects

Department of Electrical Engineering and Computer Science Basic Problem (cont. ) • Browser aspects • Protect benign users by giving control to hosting site • Con. Script: browser-supported aspects • Correctness checking • Policies are easy to get wrong • Remedy: type system • Expressiveness • Wide catalog of policies • Real-world evaluation • Built into IE 8 JS interpreter and well tested

Department of Electrical Engineering and Computer Science Related Work • Static analysis: instituting policies

Department of Electrical Engineering and Computer Science Related Work • Static analysis: instituting policies as properties • Context sensitivity in JS is prohibitively high • Small widgets are more tractable, but large systems aren’t • Inference is well studied • Browser tags • Obviated need • Isolation languages • Correctness is hard

Department of Electrical Engineering and Computer Science Related Work (cont. ) • Shallow wrapping

Department of Electrical Engineering and Computer Science Related Work (cont. ) • Shallow wrapping • Not appropriate for large APIs • Susceptible to policy integrity attacks • Weaving aspects into the source • Server cost too high • Type-based pointcuts are too imprecise • DOM API can’t be rewritten • Aspect interfaces for dynamic languages • The around function is much simpler • around could be modified (before, after, etc. )

Department of Electrical Engineering and Computer Science Related Work (cont. ) • Secure aspects

Department of Electrical Engineering and Computer Science Related Work (cont. ) • Secure aspects • Don’t allow for behavioral modification of code • CONSCRIPT is the opposite model • Aspects are protected from subsequent code • Others don’t interact with non-policy code

Department of Electrical Engineering and Computer Science Main Ideas • around function • Deep

Department of Electrical Engineering and Computer Science Main Ideas • around function • Deep advice: advice propagates to function root, rather than references • Depends on the runtime and browser being uncompromised • Avoids shallow advice (wrapping), as leaks occur • C++ interpreter • Adds advice pointer and enabled bit to functions

Department of Electrical Engineering and Computer Science stack heap fish. . . display function

Department of Electrical Engineering and Computer Science stack heap fish. . . display function with. Bound Checks . . . dog draw function paint

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • C++ interpreter

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • C++ interpreter • Native functions are handled like user-defined (bit + pointer) • External functions are checked for advice registration • Hits have advice processed, misses continue normally • Bounded lookup table • Bless/curse: flip advice bit to enable/disable advice function • Automatic flipping is most efficient and effective • New scripts are sent to advice automatically • The return string is passed to the parser • Isolated reasoning and static analysis in the interpreter to prevent vulnerabilities through poisoning

Department of Electrical Engineering and Computer Science

Department of Electrical Engineering and Computer Science

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Some functionality

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Some functionality removed • with and eval • No caller access • Policies • • 17 handwritten, 2 automatic generators No kernel to user flow allowed Functions must be known at policy invocation Privilege levels: u, k and o

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Script introduction

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Script introduction policies • • • No scripts after a certain point No string arguments in set. Interval or set. Timeout No inline scripts Tags checked for whitelisted sources noinlinescript tag for certain elements • Communication restrictions • • Restrict XMLHttp. Request to secure connections No access to cookies (http access only) Limit post. Message (cross-frame messages) to whitelist Limit cross-domain requests to a whitelist

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • DOM Interactions

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • DOM Interactions • • • Prevent links from accessing cookies Limit the number of popup windows (or window movement) Disable dynamic iframe generation Whitelist for URL redirections Disable abuse of resources (modal dialogs) • API Programming Reliability Constraints • Simple comparisons for $ operator in Jquery • No null returns for $ operator • Staged eval restrictions

Department of Electrical Engineering and Computer Science Policies: Easy to get Wrong 1. var

Department of Electrical Engineering and Computer Science Policies: Easy to get Wrong 1. var ok. Origin={"http: //www. google. com": true}; 2. around(window. post. Message, 3. function (post, msg, target) { 4. if (!ok. Origin[target]) { 5. throw ’err’; 6. } else { 7. return post. call(this, msg, target); 8. } 9. });

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Static typing

Department of Electrical Engineering and Computer Science Main Ideas (cont. ) • Static typing system • Use ML-like typing system to annotate privilege level of objections • K (‘kernel’), U (‘user’), O (protected ‘object’) • Track how information can flow • Automatic policy generation (Script#) • Look for unused methods in training data, and blacklist errors as malicious • Integrate with rules auto-generated from other libraries (private methods)

Department of Electrical Engineering and Computer Science

Department of Electrical Engineering and Computer Science

Department of Electrical Engineering and Computer Science Evaluation and Results • 969 lines of

Department of Electrical Engineering and Computer Science Evaluation and Results • 969 lines of Java. Script at 60 locations • Without boilerplate code, about 8 lines per location • Some features disabled • arguments. callee • Performance cost is 2 -3 x better than others • 10, 000 invocations of each target function • Advice mechanism + original function counted • Tried on native, user-defined, and DOM functions • 24 microsecond cost for environment creation

Department of Electrical Engineering and Computer Science Evaluation and Results (cont. ) • CPU

Department of Electrical Engineering and Computer Science Evaluation and Results (cont. ) • CPU bound • Considerably faster than the Do. Co. Mo system • For private methods, at most 0. 3% overhead • Less than 3. 5% range of error • Intrusion detection policy very small • 7% overhead with a 46% standard deviation • No intrusion detection alarms while testing • 0. 7 KB average file size increase • Policy file size mostly constant, even with large source

Department of Electrical Engineering and Computer Science Micro Benchmarks

Department of Electrical Engineering and Computer Science Micro Benchmarks

Department of Electrical Engineering and Computer Science Macro Benchmarks

Department of Electrical Engineering and Computer Science Macro Benchmarks

Department of Electrical Engineering and Computer Science Code Size Increase

Department of Electrical Engineering and Computer Science Code Size Increase

Department of Electrical Engineering and Computer Science Open Issues • Library loading and static

Department of Electrical Engineering and Computer Science Open Issues • Library loading and static analysis • If code is loaded before aspect registration • Static analysis could be preferable • with and eval are missing • Set. Timeout unsafe without policy enforcement • Type inference incomplete • Browser support is required

Department of Electrical Engineering and Computer Science Open Issues (cont. ) • Automatic policy

Department of Electrical Engineering and Computer Science Open Issues (cont. ) • Automatic policy generation • Policies come with host page • Attackers could use unsupported frameworks

Department of Electrical Engineering and Computer Science Questions?

Department of Electrical Engineering and Computer Science Questions?