Presented by Vaibhav Rastogi A new protection scenario Current browsers try to separate host system from Web Websites evolved into web applications Lot of private data on the web Financial transactions ID: 1022472
Download Presentation The PPT/PDF document "The Multi-Principal OS Construction of t..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. The Multi-Principal OS Construction of the Gazelle Web BrowserPresented by Vaibhav Rastogi
2. A new protection scenarioCurrent browsers try to separate host system from WebWebsites evolved into web applicationsLot of private data on the webFinancial transactionsWebsite principals need to be protected from each another
3. Apply multi principal OS conceptsWebsites as principalsPrincipals to be protected from each otherOS to be protected from website principalsBrowser as an OSIsolates all principals and the OS from each otherAll OS functions handled by browser kernelSystem call interface
4. GazelleBrowser kernelProvide cross principal protectionManage resourcesDefine principalsBased on website originsComplete isolation of principalsany sharing is through the kernel
5. Security ModelPrincipalsSOP – <proto, domain, port>Define resourcesDOM and script objects, cookies, display, network communicationsMake a consistent SOPplugin content, cookies
6. Architecture: KernelBrowser kernelExclusively manage all system resourcesEnforce all security policies
7. Architecture: PrincipalsAbstraction unitsProtectionFailure containmentResource allocationAll above units defined as SOP principalsAll units implemented as OS processes
8. ArchitectureA principal’s process includes all browser componentsFailure containmentEfficiencyProcess level sandboxing guarantees containment of memory exploitsPlugins interact with OS through browser kernel
9. Architecture<script>, stylesheetsRun as includers<iframe>, <object>, <img>, <embed>Run as providers
10. Architecture
11. Display and Events ProtectionDetermine display and events ownership and enforce protectionSeparate rendering and display managementTraditional OSes do not handle cross principal display protection
12. Display and Events ProtectionDual ownershipLandlord – the creatorTenant – the residentLandlord allocates part of display to tenantResources associated with displayPosition, dimensions, content (pixels), location
13. Display and Events ProtectionPosition and dimensionsDrawing isolationNavigation
14. Potentially overlapping transparent cross origin overlays.The z-axis stackRequirement: determining if the event owner corresponds to user intentLow fidelity determination leads to UI redressing attacksDisplay and Events Protection
15. 2D display delegation policyNo overdrawing allowedSeverely limitedOpaque overlay policyBetter but still has limitationsDisplay and Events Protection
16. Security AnalysisTrusted computing base assumptionCompromise is containedNo additional capabilities may be acquired by a compromised instanceCross origin vulnerabilitiesDisplay vulnerabilitiesPlugin vulnerabilities
17. ImplementationBrowser kernel implemented in C#Prototype utilizing the IE’s trident rendererCompatible with IE 7Instrument Trident to redirect resource access to browser kernelSandboxing implemented through interpositionNo plugin support
18. EvaluationWhen browsing across same origin, on par with IE and Chrome
19. EvaluationMore overhead in cross origin navigationMay be better in production version
20. EvaluationHigher memory usage, response timeUser action -> display update – roughly 77 ms
21. ComparisonGoogle ChromeSite vs SOP principalEmbedded contentPlugin contentEnforcement of policiesgoals
22. ComparisonOP browserBrowser components also isolated in different processesLot of IPC requiredFailure containment absentNo display protectionIncomplete separation of OS logic
23. LimitationsBackwards compatibilityEvaluation not very convincingOthersDisplay protection
24. Cross Origin JavaScript Capability LeaksPresented by Vaibhav Rastogi
25. Cross Origin JavaScript Capability LeaksJavaScript objects of one context should not necessarily be accessible from another DOM and JavaScript engine have different security modelsDOM – access controlJavaScript engine – object capabilitesDisparate security models lead to vulnerabilties
26. Object CapabilitiesAbility to influence an object depends on ability to designate the objectPointers obtained byAccessing properties of accessible objectsBuilt in object such as the global object or Object.prototype
27. ContributionsIdentify a new class of browser vulnerabilitiesA dynamic tool for detecting theseDiscovered several real vulnerabilitiesA new defense mechanism
28. Capability LeaksBrowser bugs may cause inter context leaksMalicious script can use the unintentionally leaked pointer to get access to the Object.prototype of the victimAffect non vulnerable sites too
29. DetectionCompute security originMark edges between objects connected with “points-to” relationMark cross origin edges as suspiciousInstrument set, deleteTake into account implicit pointersWhitelist certain edges
30. A vulnerability in WebKit
31. Create an iframe which has the following functionA vulnerability in WebKit
32. In parent frame store a pointer to exploitNavigate toCall A vulnerability in WebKit
33. DefenseAdd access control checks throughout JS engineAddresses the mismatch in the security modelsDouble layer of securityCompare active and target origins to allow/deny accessInline cache for optimization1-2% overheads in implementation
34. Comparison with other worksFBJS, ADSafe, CajaRestrict JavaScript and DOM API to enforce capability model on DOM These projects target on new code which can obey such constraintsThey must work in existing browsers – so cannot change the legacy browsersThe opposite is true for this paper
35. Comparison with other worksGazelle, OPSuspicious edges are between sandboxesHowever implementations of cross origin communication APIs like PostMessage may change the situationUnclear if such vulnerabilities existor is it?
36. ThanksCredits: http://www.usenix.org/events/sec09/tech/slides/wang.pdfhttp://www.usenix.org/events/sec09/tech/slides/barth.pdf