an analysis of browser domain isolation bugs and a light weight transparent defense mechanism l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism PowerPoint Presentation
Download Presentation
An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism

Loading in 2 Seconds...

play fullscreen
1 / 23

An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism - PowerPoint PPT Presentation


  • 276 Views
  • Uploaded on

An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism. Shuo Chen † , David Ross ‡ , Yi-Min Wang †. † Internet Services Research Center Microsoft Research. ‡ Microsoft Security Technology Unit. October 30 th , 2007.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism' - daniel_millan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
an analysis of browser domain isolation bugs and a light weight transparent defense mechanism

An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism

Shuo Chen†, David Ross‡, Yi-Min Wang†

†Internet Services Research Center

Microsoft Research

‡ Microsoft Security Technology Unit

October 30th, 2007

foundation of browser security same origin policy
Foundation of Browser Security – Same-Origin Policy
  • A browser can visit pages from benign and malicious websites at the same time.
  • Browser needs to provide an isolation mechanism so that pages from different domains cannot access each other.
    • The policy of such a mechanism is commonly referred to as the same-origin policy (SOP)
    • Otherwise, a foo.com page can do almost anything to a bank.com page
      • Info leak: steal the user’s personal information in myBank.com
      • Request forgery: transfer the user’s money to other places.
isolation is important but difficult
Isolation is important, but difficult
  • Some SOPs are not clearly defined.
    • The industry still needs to define some specific SOPs.
  • However, even for well-defined SOPs, the current implementations of the isolation mechanisms are surprisingly error-prone.
    • IE, Firefox, Netscape, Opera all had bugs in their implementations.
  • Demos: attacks against IE 6 (on WinXP)
how can we eliminate implementation bugs in the isolation mechanism
How can we eliminate implementation bugs in the isolation mechanism
  • Keep patching? Not a real solution, not effective for future bugs.
  • Perform a thorough code review of the browser code base?
    • Not realistic. The code base is huge, bugs are much trickier than buffer overruns.
  • What kind of solution do we want?
    • Comprehensive: solve this class of bugs
    • Transparent: no need to change web applications
    • Light-weight: low performance overhead
    • Self-contained correctness: can be implemented correctly with only limited understanding of existing browser code base
our proposal script accenting
Our proposal: Script Accenting
  • In human languages, accent is essentially an identifier of a person’s origin that is carried in communications
  • Script accenting
    • Each domain is associated with an “accent key”.
    • Scripts and HTML object names are represented in their accented forms at the interface between the script engine and the HTML engine.
    • Two frames cannot interfere if they have different accent keys (no need for an explicit check for the domain IDs)
what s so difficult about sop check
What's so difficult about SOP check?
  • Frame A’s domain is x, frame B’s domain is y. Isn’t it easy to simply check x==y?
  • No, it’s much more complicated than this
    • There are unexpected execution paths in the system to bypass the check or feed incorrect domain IDs to the check.
    • Exploit scenarios take advantage of many complex mechanisms in the browser.
    • Surprisingly smart ways of exploits!
exploiting the interactions between ie and windows shell
Exploiting the Interactions between IE and Windows Shell

Windows ShellAddress Parser

Window Shell

javascript: doEvil

file: javascript: doEvil

IE

Salary=$1234

Direct deposit settings …

Frame2 = open(“http://payroll”, “frame2”);

open(“file: javascript: doEvil”, “frame2”)

Frame2: URL=http://payroll

Frame1: URL=http://evil

exploiting function aliasing
Exploiting Function Aliasing

(1) Set a timer in Frame2 to execute a statement after 1 second

(2) Frame2.location.assign

=window.location.assign

(3) Navigate Frame1 to http://payroll

After 1 second, execute:

“location.assign(‘

javascript:doEvil’)”

Frame1: URL=http://evil

Frame2: URL=http://evil

Frame1: URL=http://payroll

exploiting the excessive expressiveness of frame navigation calls
Exploiting the Excessive Expressiveness of Frame Navigation Calls

Frame1: URL=http://payroll

Frame2: URL=http://payroll

Frame0 executes a statement:

Frame2.open(“javascript:doEvil”,Frame1)

Frame0: URL=http://evil

exploiting the semantics of user events
Exploiting the Semantics of User Events

document.body.setCapture()

onClick() {

reference to the document in

Frame1 by event.srcElement

}

Frame1: URL=http://payroll

Frame0: URL=http://evil

what we learned from the attacks
What we learned from the attacks
  • The causes
    • The SOP check is bypassed in some attack scenarios (the check may not be triggered)
    • The SOP check is a single-point check buried deep in the call stack
      • At the time of check, there are confusions of the domain-IDs.
  • Developers cannot anticipate all these scenarios.
    • Involving too many modules, too complex logic combinations
the implementation
The implementation
  • Each domain D is assigned a random number as its accent key KD
  • The current implementation uses  (i.e., XOR)
    • To accent script S in domain D: S  KD
  • Two basic and easy rules in the implementation
    • Rule of script ownership
      • A script is owned by the frame that supplies the source code of the script, and should be accented at the time when its source code is supplied.
    • Rule of object ownership
      • Every object is owned by the frame that hosts the DOM tree of the object, and is always referenced by its accented name.
attack 1 revisited
Attack 1 Revisited:

Windows ShellAddress Parser

Window Shell

javascript

Filename, not a javascript

javascript: doEvil

file: javascript: doEvil

IE

Frame2 = open(“http://payroll”, “frame2”);

open(“file: javascript: doEvil”, “frame2”)

Unrecognizable script code

Frame2: URL=http://payroll

Frame1: URL=http://evil

attack 2 revisited
Attack 2 Revisited

(1) Set a timer in Frame2 to execute a statement after 1 second

(2) Frame2.location.assign

=window.location.assign

(3) Navigate Frame1 to http://payroll

After 1 second, execute:

“location.assign(‘

javascript:doEvil’)”

Frame1: URL=http://evil

Frame2: URL=http://evil

Frame1: URL=http://payroll

The script is accented using evil’s key, but deaccented using payroll’s key

attack 3 revisited
Attack 3 Revisited

Frame1: URL=http://payroll

Frame2: URL=http://payroll

Frame0 executes a statement:

Frame2.open(“javascript:doEvil”,Frame1)

Frame0: URL=http://evil

The script is accented using evil’s key (Frame0), but deaccented using payroll’s key (Frame1)

attack 4 revisited
Attack 4 Revisited

document.body.setCapture()

onClick() {

reference to

event.srcElement

}

Frame1: URL=http://payroll

Frame0: URL=http://evil

Names of objects under srcElement are deaccented using payroll’s key.

compatibility and performance
Compatibility and Performance
  • Compatibility
    • Existing web applications do not need any changes. They can run normally without knowing the existence of the accenting mechanism.
  • Performance
    • The measurement about end-to-end browsing time did not show any noticeable slowdown.
      • (despite a 3.16% worst-case performance overhead)
conclusions
Conclusions
  • We studied previous browser-isolation bugs, and identified key challenges in eliminating these bugs.
  • We proposed the script accenting approach
    • Easy to reason about its correctness without understanding the complex logic of existing browser code base.
  • Evaluations show its comprehensive protection, compatibility with existing applications, and very small performance overhead.