An analysis of browser domain isolation bugs and a light weight transparent defense mechanism
Download
1 / 23

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


  • 260 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 l.jpg

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 l.jpg
Foundation of Browser Security – Same-Origin Policy Light-Weight Transparent Defense Mechanism

  • 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 l.jpg
Isolation is important, but difficult Light-Weight Transparent Defense Mechanism

  • 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 l.jpg
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 l.jpg
Our proposal: Script Accenting mechanism

  • 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 l.jpg
What's so difficult about SOP check? mechanism

  • 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 l.jpg
Exploiting the Interactions between IE and Windows Shell mechanism

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 l.jpg
Exploiting Function Aliasing mechanism

(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 l.jpg
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 l.jpg
Exploiting the Semantics of User Events Calls

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 l.jpg
What we learned from the attacks Calls

  • 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 l.jpg
The implementation Calls

  • 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 l.jpg
Attack 1 Revisited: Calls

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 l.jpg
Attack 2 Revisited Calls

(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 l.jpg
Attack 3 Revisited Calls

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 l.jpg
Attack 4 Revisited Calls

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 l.jpg
Compatibility and Performance Calls

  • 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 l.jpg
Conclusions Calls

  • 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.


ad