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

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

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

3. 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)

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

5. 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)

6. A Study of Real Attacks

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

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

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

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

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

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

13. Implementation of Script Accenting Mechanism

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

15. Accenting Script Source Code

16. Accenting Object Name Queries

17. Evaluations

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

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

20. 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)

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

22. 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)

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