Secure Web Browsing with OP and Chrome

1. Secure Web Browsingwith OP and Chrome by Mohan Dhawan

3. More Troubles Current browsers are plagued by Script based Attacks XSS, drive by downloads, pharming attacks, DNS Rebinding Compromised / malicious plugins and extensions Statistics for 2007 Internet Explorer had 93 security vulnerabilities, Mozilla browsers had 74, Safari had 29, and Opera had 9 301 reported vulnerabilities in browser plugins [OP Browser]

4. Outline The problem Related Work OP Web Browser Evaluation Discussion Way Forward ? Conclusion

5. The problem Malicious script execution XSS, XSRF, etc. Sand-boxing Browsers are a multi-principal platform data and code (lots of scripts) from mutually distrusting sites interact iGoogle, Microsoft Live single-application model provides little isolation or security limited built-in security by enforcing same origin policy too restrictive Handling compromised / malicious plugins and extensions have full browser privileges plugin writers implement ad-hoc policies

6. Related Work Language Abstractions MashupOS <Sandbox> <ServiceInstance> Helen Wang et al � SOSP 07 BEEP <div class = �noexecute� > Trevor Jim et al � IWWW 07

7. Related Work (contd.) Architecture Tahoma web applications should not be trusted browsers should not be trusted Separate browser instances with VMs Richard Cox et al � CCS 07

8. Related Work (contd.) Modify the browser Script Accent Domain specific �accents� for scripts and HTML object names �An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defence Mechanism� - Shuo Chen et al. - CCS 07 Dynamic Tainting Track flow of sensitive information inside the web browser �Cross Site Scripting Prevention with Dynamic Tainting and Static Analysis� - Phillip Vogt et al. � NDSS 07 Different isolation policy Enforces access using server�s X.509 certificates and keys �Dynamic Pharming Attacks and Locked Same-origin Policies for Web Browsers� - Chris Karlof et al. - CCS 07

9. New Solutions Build browser from scratch Keeping in mind web 2.0 applications secure script execution Latest efforts OP Chris Grier, Shuo Tang, Samuel King � Oakland 08 Chrome Google

10. OP Web Browser Primary Goal is to ensure Secure Web Browsing prevent browser based attacks from happening limit the damage in case of a successful compromise provide ability to recover from successful attacks

11. Threat Model & Assumptions Designed to operate under malicious influence Attacks originated from a web page could potentially target any part of the browser Attacker can have complete control over the content Circle of Trust OS and JVM to enforce isolation DNS names for labelling security contexts

12. OP Guiding Principles Simple and explicit communication between components Clean separation of functionality and security Explicit interfaces reduce number of control flow paths Strong isolation between browser components Prevents unanticipated and unaudited interactions Monitor components to ensure faithful execution Delegate some security logic Compatible with existing technologies Goal is to secure web browsing

13. OP Architecture Main subsystems the web page subsystem, a network component, a storage component, a UI component, and a browser kernel Each subsystem runs within separate OS level processes SELinux sand�boxing to limit subsystem interaction with OS

14. OP Architecture (contd.)

15. Subsystem Privileges

16. Browser Kernel Manage subsystems Creates and deletes all processes and subsystems Creates web-page instances on demand Multiplexes between existing web-pages on user navigation Manages communication between subsystems interposes on all message communication Use of OS level pipes Mapping of subsystems and pipes prevents spoofing Single threaded, event driven component All messages have unique ID

17. Browser Kernel (contd.) Manages access control Browser processes tagged with a security context Tag depends on initial messages intercepted Maintains detailed security audit log Records all messages between subsystem Helps in forensic analysis in event of system compromise

18. Web Page Subsystem HTML parsing and rendering Engine KHTML JavaScript Interpreter Rhino (Java based)? provides strong isolation Plugins are separate OS level processes provide better isolation Xvnc server which renders the visual content

19. Web Page Subsystem (contd.)

20. UI, Network & Storage Subsystems UI is built in Java do not render content directly Each web page instance renders its own content File System is accessed only through UI system Storage component uses sqlite-db to store persistent data like cookies Network subsystem implements HTTP

21. Browser Plugins Allow browsers to view additional mime types loaded as a DLLs or shared objects Communicate with the browser through a well defined API Run in the same address space as the browser Complicates security as they are given unchecked access to browser internals Successful attack on a plugin can lead to a full system compromise Plugins writers may implement their own ad�hoc security

22. Plugins and OP Each instance is treated as a separate process assigned a label (security context) by the kernel By inspecting the messages Plugin Access Control done by browser kernel Uses the same security mechanisms and policies as for the rest of the browser subsystems

23. OP and Plugin Security Plugin Security Policies Provider domain policy allows a plugin in a page to use the permissions of the plugin content source Plugin freedom policy allows additional outgoing network accesses for plugins to support peer-to-peer applications can only talk to network and storage subsystems

24. Formal Verification OP browser modeled using Maude (reasoning engine) both interpreter and language Formally specify browser components in terms of invariants over finite space Program invariants include access control policies Visual invariants include UI tampering Address bar spoofing Maude checks for states that violate invariants

25. Attack Analysis Build a dependency graph between browser level objects Objects connected by causal events Backtracker graph generation algorithm is used Backward algorithm is used to find origin of an attack Forward algorithm is used to track effects of an attack Great analyzing tool once an attack has occurred

26. Performance Evaluation

27. Discussion Apply OS principles for security Process abstraction to provide protection and isolation Process management How long to cache the web page instance ? Messages to subsystems analogous to syscalls Access to protected resources via the kernel Browser kernel intercepts all messages Plugins are like device drivers Hard to secure OP provides protection against buggy plugins Not against malicious ones

28. Discussion (contd.) Performance No micro-benchmark performance figures Comparative analysis of how OP stands out with other browsers combating the known web exploits (e.g. XSS, XSRF etc.) Future works Enhance OP browser to prevent common attacks DNS rebinding Automated detection of crashed and malfunctioning subsystems to trigger recovery actions

29. Way Forward ? Chrome Developed by Google Apple�s WebKit Open source rendering engine for chrome Mozilla Developed for web 2.0 applications Browsers are multi-principal

30. Design Goals New Age browsers must be More stable Faster More secure Simpler user interface

31. Legacy Browsers

32. Chrome Design Different processes for different tabs separate address space No fragmentation of memory unlike legacy browsers isolation offers protection Separate thread for JavaScript

33. Speed : WebKit and V8 Webkit Efficient memory usage Easily adapted to embedded devices Easy interface for developers V8 Virtual machine for JavaScript Provides safety and platfrom independence Hidden class transition

34. Hidden Class Transition function Point(x,y){ this.x = x; this.y = y; }

35. Machine Code Generation

36. Speed (contd.) V8 Machine code generation Dynamic code generation Cache code for future reference Garbage collection Heap segmented as new space and old space GC entails Stop program execution Process only part of the heap in most GC cycles Always know precise location of all pointers and objects Updates all pointers to object if it moves to old space

37. Chrome features Separation of the browser and tabs processes Tabs no longer bound to a window Privacy mode Read-only mode No logging No history saved Session cookies deleted on closing the window Web apps have their own chrome

38. Security and Safe Browsing Malware and Phishing Huge monetary incentive Chrome continuously downloads lists of phishing and malware sites Sandboxing Security from malware All processes stripped of their rights to read / write to sensitive areas Cannot interact among themselves

39. Security Levels

40. Sandboxing

41. Plugins Plugins run as a separate process Unlike legacy browsers where plugins, HTML and JavaScript run as a single process

42. Overall Picture

43. Google Gears Adds a set of API to the browser for developers Plugin that extends browser capabilities Create web apps that can run offline Key features A local server, to cache and serve application A database, to store and access data from within the browser A worker thread pool, to make web apps more responsive Open standard

44. Discussion Similarities with OP Browser split into components Each within its own protection domain Both have a main process Browser Kernel, Chrome Process Plugins are executed as separate processes No details about extension handling Differences with OP Separate thread for JavaScript VM Separation of browser and tabs

45. Discussion (contd.) New Features Dynamic code generation Phishing and Malware protection Gears Open Issues Secure script execution Handling malicious plugins and extensions Framework for web 2.0 applications

46. Conclusion OP uses OS features to secure web browsers Chrome extends OP, adds security and speed

47. Thank You