Transcript Fabrice-cs6204-spring11x

Cloud Environment
Spring 11
0





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
Taken from: http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.html
2
About me:
Samy Kamkar
Taken from: http://www.f-secure.com/weblog/archives/00000930.html
3
Problem in Current Browser Architecture
Motivation
Gazelle’s Architecture and Design
Performance Study
Future Work
Conclusion
4
 Support dynamic web contents
 Evolved into multi-principal operating
environment
 No exclusive control for protection
 No fair sharing of system resources
 Principal is domain
5

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 allowed
 Allow scripts to access DOM properties and methods
across domains
Principal
<iframe
src=“http://a.com”>
</iframe>
X
<iframe
src=“http://b.com”>
</iframe>
6

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
 Enforce security on plugins and control
their access to the local Operating System
Assure stronger
Provide exclusive
 security
Total isolation
principals
and
and between
control
management
their respective
robustness
withresources to all system
acceptable
resourcesisamong
 Any
sharing between principals
done
performance
site principals
through
cross-principal web
communication
8
Problem in Current Browser Architecture
Motivation
Gazelle’s Architecture and Design
Performance Study
Future Work
Conclusion
9
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
10

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
<iframe> they are placed in different principal
instance
Run everything as a separate process
11
 Creation of separate
plugin instance for thirdparty plugin and/or crosssite scripts
 Interdiction for the plugin
instance to invoke the
getCrossOriginContent()
 The plugin instance can
interact with style sheets
only through the browser
instance
12



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

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



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
Landlord: somesite.com
Tenant
<iframe
src=“a.com”>
</iframe>
Window
15

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

Landlord, tenant Access Control Policy:
◦ Position and dimensions
◦ Drawing isolation
◦ Navigation

Cross-Principal Events Protection
◦ Opaque Overlay Policy
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)
17

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
Problem in Current Browser Architecture
Motivation
Gazelle’s Architecture and Design
Performance Study
Future Work
Conclusion
19
Comparison with known browsers
20
Gazelle overheads:
21



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

Gazelle, fully operational IE-based multiprincipal OS for website principals

Provides resource protection management

Resistant to failure of one or more principals

Assures legacy protection against crossorigin script, cross-principal and crossprocess display
23
???
24