The Multi-Principal OS Construction of the Gazelle Web Brow - PowerPoint Presentation

Slide1

The Multi-Principal OS Construction of the Gazelle Web Browser

Cloud EnvironmentSpring 11

0Slide2

Microsoft Research Browser (2009)Multi-Principal Environment with Browser OSNext

Step Towards Secure Browser Written in C#Main Contributors:

Helen J. Wang - Microsoft

Piali Choudhury - MicrosoftHerman Venter - MicrosoftChris Grier - University of Illinois at U-CAlexander Moshchuk - University of WashingtonSam King - University of Illinois at U-C

1

Quick Background about GazelleSlide3

2

Beware of Clickjacking

Attack!

Taken from: http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.htmlSlide4

3

MySpace Worm

Samy

Cross-Site Scripting (XSS) Samy KamkarAbout me:

Taken from: http://www.f-secure.com/weblog/archives/00000930.htmlSlide5

Outline

4Slide6

5

Client WebPages

Support dynamic web contents

Evolved into multi-principal operating environment No exclusive control for protection No fair sharing of system resources Principal is domain Slide7

Same-Origin Policy (SOP)Origin defined by: <protocol, domain-name, port>Two resources are same origin

iff these values are identical No cross-domain interactions allowedAllow scripts to access DOM properties and methods across domains

6

Standard Browser Security <iframe

src=“http://a.com

”>

</

iframe

>

<

iframe

src

=“http://

b

.com

”>

</

iframe

>

X

PrincipalSlide8

External scripts run with privileges of the principalDistrusting external scripts may weaken security

E.g: igoogle inline gadgetsCross-origin vulnerabilitiesUnchecked user input

Fault

-tolerant handling of CSS leads to security weaknessScripts can get access to cookies belonging to a domain despite patch restrictions7SOP WeaknessesSlide9

Gazelle Goal

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 Slide10

Outline

9Slide11

10

Gazelle Basic Architecture

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 instancesSlide12

Principals are also know as unit of protectionPrincipal

instance assures failure containment, rendering content into bitmap objects and resource allocation

P

rincipals are placed into separate protection domains (restricted or sandboxes OS process)cs.vt.edu and math.vt.edu are two different principalsIf site a.com embed a principal b.com in an <iframe> they are placed in different principal instance

11

Principal Instance

Run everything

as a separate

proces

sSlide13

12

Principal Instance (

con’t

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

Exclusively responsible for managing principals and system resources

Dispatch all events including user events generated by local OS to the appropriate principal instanceAssure the creation of protection domain before rendering the target principal

13

The Browser KernelSlide15

System call supported for content fetching:

getSamOriginContent(URL)getCrossOriginContent(URL)delegate(URL

,

windowSpec)Provide policies to manage and display bitmap objects created by principal instanceDiscern display and events ownershipEnforce that principal can only draw in its allocated spaceDispatch UI events to only the principal that the user is interacting14

The Browser Kernel (

con’t

)Slide16

Implemented using .NET Graphics and Bitmap LibraryWindow is a unit of display allocation and delegationParent, child terminologies are replaced respectively by landlord and tenant

15

Display Management

<iframe src=“a.com

”></iframe>

Tenant

Landlord:

somesite.com

WindowSlide17

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 callFor each created window, the kernel records the following state: The landlord, tenant, position, dimension, pixels, URL location of the window content

16

Display Management (con’t)Slide18

Landlord, tenant Access C

ontrol Policy:Position and dimensionsDrawing isolationNavigationCross-Principal Events Protection

Opaque Overlay Policy

17Display Management (con’t)(2)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

)Slide19

Browser Kernel: 5k lines of C# code

Communication with principal instance is implemented as asynchronous XML-based messages sent over named pipesBrowser Instance (runtime):Uses Trident webBrowser

control with Trident’s COM interface

Uses a local proxy for rerouting all network requests to the browser kernel18Implementation SummarySlide20

Outline

19Slide21

20

Performance Study

Comparison with known browsersSlide22

21

Performance Study (

con’t

)Gazelle overheads:Slide23

Exploring fair sharing among principals in the browser kernelTradeoffs between compatibility and security in browser policy design

Optimization of the local proxy communication for network interposition22

Future Work Slide24

Gazelle, fully operational IE-based multi-principal OS for website principalsProvides resource protection management

Resistant to failure of one or more principalsAssures legacy protection against cross-origin script, cross-principal and cross-process display

23

ConclusionSlide25

24

???