Chrome may be secure, but if the extensions aren't, it doesn't matter. Michael Kassner asks the experts why extensions are vulnerable and what's being done about it.
Chrome extension: A small software program that can modify and enhance the functionality of the Chrome web browser.
"There are bugs in Chrome but they're very hard to exploit. I have a Chrome vulnerability right now but I don't know how to exploit it."
2010 was also when I started writing about Chrome and Chrome extensions. During my research for the earlier article about extensions, I was introduced to Adrienne Porter Felt. You may recognize the name; Adrienne has provided expert advice for many of my articles.
It just so happens Google listens to Adrienne as well. The paper "Protecting Browsers from Extension Vulnerabilities," written by her research team was instrumental in the development of Chrome's innovative extension system.
When Adrienne speaks...
Last September, a Google Alert email mentioned Adrienne had written about security bugs in Chrome extensions. Hmm. Mental note to self — Adrienne was working on something important.
In February of this year, my suspicion was justified. Adrienne, along with Nicholas Carlini and David Wagner (Adrienne's advisor) released "An Evaluation of the Google Chrome Extension Security Architecture."
The paper starts out:
"Vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users' private data and credentials."
Déjà vu struck when I read that. In 2009, I wrote about Firefox having the same problem. Well, I could see it was time to call Adrienne and see what's up. Here's what she had to say.Kassner: Hello, Adrienne. Before we get to your latest paper, would you bring us up to speed on the security features implemented in the Chrome extension system? Porter Felt: In 2009, Google Chrome introduced a new extension platform with several features intended to prevent and mitigate extension vulnerabilities:
- Privilege separation: Extensions are built from two types of components, which are isolated from each other — content scripts and extension cores. Content scripts interact with websites and execute with no privileges. Extension cores do not directly interact with websites and execute with the extension's full privileges.
- Isolated worlds: Content scripts can read and modify website content, but content scripts and websites have separate program heaps so websites cannot access content scripts' functions or variables.
- Permissions: Each extension comes packaged with a list of permissions, which govern access to the browser APIs and web domains. If an extension has a core vulnerability, the attacker will only gain access to the permissions the vulnerable extension already has.
"27 of the 100 extensions contain one or more vulnerabilities, for a total of 51 vulnerabilities. The set of vulnerable extensions includes 7 extensions with more than 300,000 users each."
Why is it important to make sure extensions are not vulnerable?Porter Felt: Extensions are fairly powerful — they can read users' browsing history, passwords, email, etc. If an attacker compromises an extension, the attacker can get access to this personal information, too. Kassner: Could you briefly explain how you determined if an extension was vulnerable? Porter Felt: I worked with a fantastic undergraduate student at Cal named Nicholas Carlini. First, he would exercise the user interfaces of the extensions while monitoring their network traffic. Then, he read and searched through the extensions' source code to find any attacks. I then reviewed each of the potential vulnerabilities to ensure they were real. We then built attacks to demonstrate the vulnerabilities truly existed. Kassner: The paper seems particularly concerned about extension-core vulnerabilities. Why is that? Porter Felt: The "core" is the most powerful part of the extension, so a vulnerability in an extension core yields the most privileges to an attacker. The extension core includes invisible background code, options, and any other HTML the extension provides. Kassner: One thing confused me:
"Extensions can add vulnerabilities to web sites."
Are you saying an attacker can use a vulnerable extension to cause problems for websites?Porter Felt: Some extensions modify websites — to remove ads, for example. If the extension makes a mistake when it's editing the website, it might add a vulnerability to the website. So, even though the website might be secure by default, the new vulnerability would allow an attacker to compromise the confidentiality or integrity of the website. Kassner: I read the following:
"We propose and evaluate new defenses. This study partially motivated Chrome's adoption of a new mandatory security mechanism."
What did you propose?Porter Felt: Most developers are not security experts — their expertise is elsewhere. As our study demonstrated, developers don't follow security best-practices on their own.
We propose to ban certain unsafe coding practices, so developers can't make these mistakes. We looked at four types of unsafe coding practices and found banning two or three of them would prevent most of the vulnerabilities with little added cost to developers.
Chrome now bans three of the unsafe coding practices for extensions. I expect the vulnerability rate will dramatically decrease as developers begin upgrading their extensions.Kassner: I have to applaud Google for once again listening — from their blog entry "More secure extensions," by default:
Adrienne, I have one last question. Until extension developers adopt best practices, what can users do to protect themselves?Porter Felt: Personally, I disable extensions when I am using high-risk, public networks (airports and hotel Wi-Fi). I don't think there is much reason to be concerned when you are using trusted networks, like your home or corporate networks. Final thoughts
Adrienne wanted me to mention their paper has been peer-reviewed and will be officially published at Usenix Security 2012. And, the list of 100 tested extensions and how they fared is at the end of the team's paper.
I'd like to thank Adrienne, David, and Nicholas for making our digital lives a bit more secure.