In our earliest discussions about the extension system, we knew we wanted to raise the bar for security, but how can we secure the platform while still letting developers create awesome extensions that have rich interactions with web pages? During our threat analysis, we realized there were two main security concerns: malicious extensions and "benign-but-buggy" extensions.

A malicious extension is an extension written by an ill-intentioned developer. For example, a malicious extension might record your passwords and send them to back to a central server. The tricky part about defending against malicious extensions is that there are well-intentioned extensions that do exactly the same thing. Our defenses against malicious extensions focus on helping the user avoid installing malicious extensions in the first place:
  1. We expect most users to install extensions from the gallery, where each extension has a reputation. We expect malicious extensions will have a low reputation and will have difficulty attracting many users. If a malicious extension is discovered in the gallery, we will remove it from the gallery.

  2. When installing extensions outside the gallery, the user experience for installing an extension is very similar to the experience for running a native executable. If an attacker can trick the user into installing a malicious extension, the attacker might as well trick the user into running a malicious executable. In this way, the extension system avoids increasing the attack surface.
To help protect against vulnerabilities in benign-but-buggy extensions, we employ the time-tested principles of least privilege and privilege separation. Each extension declares the privileges it needs in its manifest. If the extension is later compromised, the attacker will be limited to those privileges. For example, the Gmail Checker extension declares that it wishes to interact with Gmail. If the extension is somehow compromised, the attacker will not be granted the privilege to access your bank.

To achieve privilege separation, each extension is divided into two pieces, a background page and content scripts. The background page has the lion's share of the extensions privileges but is isolated from direct contact with web pages. Content scripts can interact directly with web pages but are granted few additional privileges. Of course, the two can communicate, but dividing extensions into these components means a vulnerability in a content script does not necessarily leak all the extension's privileges to the attacker.

Finally, we utilize our multi-process architecture and sandboxing technology to provide strong isolation between web content, extensions, and the browser. Extensions run in a separate operating system process from the browser kernel and from web content, helping prevent malicious web sites from compromising extensions and malicious extensions from compromising the browser kernel. To facilitate rich interaction, content scripts run in-process with web content, but we run content scripts in an "isolated world" where they are protected from the page's JavaScript.

Of course, attackers will write malicious extensions and well-intentioned developers will write buggy extensions. The extension system improves security by making it easier for developers to write secure extensions. If you would like to learn more about the security of the extension system, you can watch our video or read our academic paper describing all the details.

Posted by Adam Barth, Software Engineer