An Evaluation of the Google Chrome Extension Security Architecture

1. An Evaluation of the Google Chrome Extension Security Architecture Nicholas Carlini, Adrienne Porter Felt, and David Wagner University of California, Berkeley USENIX Security Symposium 2012 2012-07-16 曾毓傑

2. Outline • Introduction • Extension Security Background • Extension Security Review • Evaluation of Isolated Worlds • Evaluation of Privilege Separation • Evaluation of Permission System • Defenses • Defenses Evaluation • Conclusion

3. Introduction • Most browser extensions are written by well-meaning developers who are not security experts • Google Chrome employs three mechanisms to prevent and mitigate extension vulnerabilities • Isolated WorldsSeparate extension’s JavaScript heap from web page’s heap • Privilege SeparationSeparate extension into two parts: content script and core extensions • PermissionsPredefine a list of permission that extension needs

4. Extension Security Background • We focus on non-malicious extensions that are vulnerable to external attacks: Benign-but-buggy extensions • Two types of attacks are possible • Network AttackersAdd malicious data into HTTP traffic reading from extensionAdd HTTP script into HTTPS web-page • Web AttackersExtension treat website’s data or functions as trusted Network Attacker Execute Untrusted Data Untrusted Data Execute Modified Data Modified Data Original Data

5. Extension Architecture

6. Chrome Security Model • Isolated WorldsExtension access a copy of DOM elements, different heap

7. Chrome Security Model (Cont.) • Privilege SeparationCore extension can access Browser API but not page’s DOMContent script can access page’s DOM but not Browser APITwo components communicate with each other using Message Passing script

8. Chrome Security Model (Cont.) • PermissionsA Manifest.json file listing permission needed of the extensionEach element is mapping to a certain Browser API module or a domain needed to access

9. Chrome Security Model (Cont.) • Content Security Policy (CSP)Client-side HTML policy system to restrict some type of JavaScript to be executed on the pageNot implemented when the research is working, so we won’t discuss this part

10. Extension Security Review • 100 Google Chrome Extension is evaluated • 50 most popular extensions • 50 randomly selected extensions • Three types of methodology is applied to the analysis • Black-box testing • Source code analysis • Holistic testing • 40% of the extensions contains vulnerabilities, totally 70 vulnerabilities are found from those extensions

11. Extension Security Review (Cont.)

12. Evaluation of Isolated Worlds • The protection of Isolated Worlds is largely succeeds • Only 3/100 extensions has content script vulnerabilities • Four possible security challenges needs to be noticed • Data as HTML – untrusted data been inserted into page • Eval – code will run in content script’s isolated world • Click Injection – unwanted events would be triggered • Prototypes and Capabilities – JavaScript prototype mechanism • Isolated Worlds defeats two of them, but not Eval and Click Injection

13. Evaluation of Privilege Separation • Privilege Separation is intended to shield the privileged core extension from attacks • 61/100 has content script, 23/61(38%) has vulnerabilities by accident or intentionally • Privilege Separation protect a content script vulnerability 62% of the time

14. Evaluation of Privilege Separation (Cont.) • Possible attacks • Vulnerable Content Script – ask core extension to trigger arbitrary HTTP XHRs • AdBlockgets window object which has eval()functionality • Web Developer insert messages into popup page, which is controlled by the core extension • Website Metadata Vulnerabilities – some malicious data may contain in website metadata • Direct Network Attacks – malicious data from HTTP XHRs or scripts

15. Evaluation of Privilege Separation (Cont.) • Privilege Separation fully protect 62% of extensions, still good enough to protect core extension from attacks • Developers may accidentally or intentionally write bad code if there is no privilege separation

16. Evaluation of Permission System • Permission system restrict the modules can be used in core extension • If the extension is compromised, attackers can only get the permissions extension predefined in the Manifest.json file • Popular permissions requested by the 27 extensions with core extension vulnerabilities

17. Evaluation of Permission System (Cont.) • Impact of those vulnerabilities • Critical – Run arbitrary code on user’s system • High – Access DOM of all HTTP(S) websites • Medium – Access DOM of financial or important personal data • Low – Access DOM of specific websites that do not contain sensitive data • None – Does not leak any permissions

18. Evaluation of Permission System (Cont.) • Developers would be unwilling to take the time to specify the correct set of permissions, which increase the danger once extension is compromised • Permission System helps mitigate these vulnerabilities in practice, thus have a positive impact on system security

19. Defenses • Four additional defenses is introduced to increase the security of extension • Banning HTTP Scripts • Use HTTPS to fetch script to prevent Man-in-the-middle attack • Include script in the extension instead of fetching it dynamically • Banning Inline Scripts • Change event binding using addEventListner() instead of onClick attribute • Banning Eval • Use function literal instead of string in setTimeout() • Use JSON.parse() instead of eval() to parse JSON data • Banning HTTP XHR • Use HTTPS XHR

20. Defenses Evaluation • Some extensions may be broken, but some extensions may fix the vulnerabilities • Recommendation: Banning HTTP Scripts and Banning Inline Script • No extensions would be permanently broken

21. Conclusion • Our work is the first to evaluate the efficacy of the Google Chrome extension platform • Perform a security review on 100 Google Chrome extensions • Isolation Worlds defeat most of the attacks