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

114th ACM Conference on Computer and Communications Security, Alexandria, VA

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

†Internet Services Research CenterMicrosoft Research

‡ Microsoft Security Technology Unit

October 30th, 2007


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.


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)


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


In human languages, accent is essentially an identifier of a person’s origin that is carried in communications

Script accentingEach 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)



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 thisThere 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!


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

Frame1: URL=http://evil

file: javascript: doEvil javascript: doEvil

Windows ShellAddress Parser

Frame2: URL=http://payroll

Salary=$1234Direct deposit settings …

Win

dow

She

ll

IE


Frame1: URL=http://evil Frame2: URL=http://evil

After 1 second, execute:“location.assign(‘ javascript:doEvil’)”

(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://payrollFrame1: URL=http://payroll


Frame1: URL=http://payroll Frame2: URL=http://payroll


Frame0 executes a statement: Frame2.open(“javascript:doEvil”,Frame1)




document.body.setCapture()

onClick() { reference to the document in Frame1 by event.srcElement}


The causesThe 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



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 ownershipA 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 ownershipEvery object is owned by the frame that hosts the DOM tree of the object, and is always referenced by its accented name.





javascript

Filename, not a javascript

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


file: javascript: doEvil javascript: doEvil

Windows ShellAddress Parser


Win

dow

She

ll

IE

Unrecognizable script code


Frame1: URL=http://evil Frame2: URL=http://evil

After 1 second, execute:“location.assign(‘ javascript:doEvil’)”

(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://payrollFrame1: URL=http://payroll

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


Frame1: URL=http://payroll Frame2: URL=http://payroll


Frame0 executes a statement: Frame2.open(“javascript:doEvil”,Frame1)

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




document.body.setCapture()

onClick() { reference to event.srcElement}

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


Compatibility Existing web applications do not need any changes. They can run normally without knowing the existence of the accenting mechanism.

PerformanceThe measurement about end-to-end browsing time did not show any noticeable slowdown.

(despite a 3.16% worst-case performance overhead)


We studied previous browser-isolation bugs, and identified key challenges in eliminating these bugs.

We proposed the script accenting approachEasy 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.

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

Documents