1. Cloud Environment Spring 11 0

2.  Microsoft Research Browser (2009)  Multi-Principal Environment with Browser OS  Next Step Towards Secure Browser  Written in C#  Main Contributors: ◦ Helen J. Wang - Microsoft ◦ Piali Choudhury - Microsoft ◦ Herman Venter - Microsoft ◦ Chris Grier - University of Illinois at U-C ◦ Alexander Moshchuk - University of Washington ◦ Sam King - University of Illinois at U-C 1

3. 2 Taken from: http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.html

4. 3 Samy Kamkar About me: Taken from: http://www.f-secure.com/weblog/archives/00000930.html

5. Problem in Current Browser ArchitectureMotivationGazelle’s Architecture and DesignPerformance StudyFuture WorkConclusion 4

6. 5  Support dynamic web contents  Evolved into multi-principal operating environment  No exclusive control for protection  No fair sharing of system resources  Principal is domain

7.  Same-Origin Policy (SOP)  Origin defined by:  Two resources are same origin iff these values are identical  No cross-domain interactions allowed  Allow scripts to access DOM properties and methods across domains 6 <iframe src=“http://a.com”> <iframe src=“http://b.com”> X Principal

8.  External scripts run with privileges of the principal ◦ Distrusting external scripts may weaken security ◦ E.g: igoogle inline gadgets  Cross-origin vulnerabilities ◦ Unchecked user input ◦ Fault-tolerant handling of CSS leads to security weakness ◦ Scripts can get access to cookies belonging to a domain despite patch restrictions 7

9. Assure stronger security and robustness with acceptable performance Provide exclusive control management to all system resources among web site principals 8  Enforce security on plugins and control their access to the local Operating System  Total isolation between principals and their respective resources  Any sharing between principals is done through cross-principal communication  Enforce security on plugins and control their access to the local Operating System  Total isolation between principals and their respective resources  Any sharing between principals is done through cross-principal communication

10. Problem in Current Browser ArchitectureMotivationGazelle’s Architecture and DesignPerformance StudyFuture WorkConclusion 9

11. 10 Gazelle Browser is divided in 3 parts:  The Principal Layer  Creates instance of an origin  The Runtime Layer  Manage scripts  Rendering pages  The Browser Kernel  Middle layer between principal and local OS  Handles runtime events  Manage and control principal instances

12.  Principals are also know as unit of protection ◦ Principal instance assures failure containment, rendering content into bitmap objects and resource allocation  Principals are placed into separate protection domains (restricted or sandboxes OS process) ◦ cs.vt.edu and math.vt.edu are two different principals ◦ If site a.com embed a principal b.com in an they are placed in different principal instance 11 Run everything as a separate process

13. 12  Creation of separate plugin instance for third- party plugin and/or cross- site scripts  Interdiction for the plugin instance to invoke the getCrossOriginContent()  The plugin instance can interact with style sheets only through the browser instance

14.  Exclusively responsible for managing principals and system resources  Dispatch all events including user events generated by local OS to the appropriate principal instance  Assure the creation of protection domain before rendering the target principal 13

15.  System call supported for content fetching: ◦ getSamOriginContent(URL) ◦ getCrossOriginContent(URL) ◦ delegate(URL, windowSpec)  Provide policies to manage and display bitmap objects created by principal instance ◦ Discern display and events ownership ◦ Enforce that principal can only draw in its allocated space ◦ Dispatch UI events to only the principal that the user is interacting 14

16.  Implemented using.NET Graphics and Bitmap Library  Window is a unit of display allocation and delegation  Parent, child terminologies are replaced respectively by landlord and tenant 15 <iframe src=“a.com”> <iframe src=“a.com”> Tenant Landlord: somesite.com Window

17.  A landlord frame can only cause navigation in tenants and has no control over frames belonging to the tenants or other principals  Window creation results in a delegate(URL, position, dimension) system call  For each created window, the kernel records the following state: ◦ The landlord, tenant, position, dimension, pixels, URL location of the window content 16

18.  Landlord, tenant Access Control Policy: ◦ Position and dimensions ◦ Drawing isolation ◦ Navigation  Cross-Principal Events Protection ◦ Opaque Overlay Policy 17 For any two dynamic content-containing windows (e.g., frames, objects): win1 and win2, win1 can overlay on win2 iff (Tenant_win1 == Tenant_win2) || (Tenantwin1 ≠T enantwin2 && win1 is opaque)

19.  Browser Kernel: ◦ 5k lines of C# code ◦ Communication with principal instance is implemented as asynchronous XML-based messages sent over named pipes  Browser Instance (runtime): ◦ Uses Trident webBrowser control with Trident’s COM interface ◦ Uses a local proxy for rerouting all network requests to the browser kernel 18

20. Problem in Current Browser ArchitectureMotivationGazelle’s Architecture and DesignPerformance StudyFuture WorkConclusion 19

21. 20 Comparison with known browsers

22. 21 Gazelle overheads:

23.  Exploring fair sharing among principals in the browser kernel  Tradeoffs between compatibility and security in browser policy design  Optimization of the local proxy communication for network interposition 22

24.  Gazelle, fully operational IE-based multi- principal OS for website principals  Provides resource protection management  Resistant to failure of one or more principals  Assures legacy protection against cross- origin script, cross-principal and cross- process display 23

25. 24 ???