An Evaluation of the Google Chrome Extension Security ArchitectureNicholas Carlini, Adrienne Porter Felt, and David WagnerUniversity of California, Berkeley

USENIX Security Symposium 2012

2012-07-16 曾毓傑1

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

2

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 Worlds

Separate 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 3

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 Attackers

Add malicious data into HTTP traffic reading from extensionAdd HTTP script into HTTPS web-page

• Web AttackersExtension treat website’s data or functions as trusted

Original DataModified Data

Execute Modified Data

Network Attacker

Untrusted Data

Execute Untrusted Data

4

Extension Architecture

5

Chrome Security Model• Isolated Worlds

Extension access a copy of DOM elements, different heap

6

Chrome Security Model (Cont.)• Privilege Separation

Core 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

7

Chrome Security Model (Cont.)• Permissions

A Manifest.json file listing permission needed of the extensionEach element is mapping to a certain Browser API module or a domain needed to access

8

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

9

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

10

Extension Security Review (Cont.)

11

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

12

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

13

Evaluation of Privilege Separation (Cont.)• Possible attacks• Vulnerable Content Script – ask core extension to trigger

arbitrary HTTP XHRs• AdBlock gets 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

14

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

15

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

16

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

17

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

18

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 19

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 20

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

21