Browser

Chrome extensions are vulnerable: Advantage, bad guys

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.

Back in 2010, Chrome became my web browser of choice. Why? For two years running, contestants at Pwn2Own did not even attempt to crack it. Charlie Miller, a several-time Pwn2Own winner pointed out:

"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.
Kassner: You reviewed 100 Chrome extensions:

"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:

"A recent study from researchers at UC Berkeley suggested these restrictions, taken together, would substantially improve the security of the extension system."

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.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

20 comments
Adrienne Porter Felt
Adrienne Porter Felt

Hi Jim, I simplified the methodology for the purpose of the article. If you read our paper, you can see the full methodology. We also captured network traces and fuzzed the extensions' network traffic. Also, our "reading" of the source code was very directed: we used grep to match sources (untrusted data) and sinks (places where data can be executed as code) and then manually traced the call graph to detect flows from sources to sinks. However, you are right: we may have missed a few vulnerabilities. In general, though, we have also found that developers tend to add new vulnerabilities to their extensions over time. I've gone back and looked over some of the extensions and have found that they have new vulnerabilities that did not exist during our review. Consequently, some extensions that were "not vulnerable" at the time of our review are now vulnerable.

JGSecurity
JGSecurity

As a Security Researcher and Consultant myself, I really enjoyed reading this and appreciate the efforts of those involved. I just wanted to point out that simply reading the source code and looking for vulnerabilities will point to the obvious ones, however, It should be noted that just because you don't notice vulnerabilities with the eye when reading the code doesn't mean they don't exist. Yes, it is probably the only way to examine all these extensions in a short time period, but it is very common to read through code many times without noticing certain vulnerabilities that can only be found by fuzzing or hacking at over time. I just do not want anyone to think that just because this report says an extension is not vulnerable does not mean that they are guaranteed to be safe using these extensions. Only time will tell if additional vulnerabilities remain to be found and exploited. I haven't looked for one but have you guys perhaps thought about doing a similar project with Firefox? Thanks for the hours of work, it is appreciated. Jim G

gbyshenk
gbyshenk

This is perhaps overly pedantic, but the idea that an extension "might add a vulnerability to the website" seems mistaken to me. An extension, being a part of the browser on the user's machine, can modify only the [i]presentation[/i] of the website's content on that user's machine. It does not modify the website itself.

jbb1
jbb1

I liked the article a great deal, however, you committed a cardinal journalistic sin in omitting a list of dangerous extensions. Surely your source must know which failed her tests. You need to get that list and publish it, ASAP. Beyond that, what's the status of work repairing vulnerable extensions? Have some been "safed?" Are some, for whatever reason, unsalvageable? You really need to better inform your readers, especially about security issues like this.

PhilippeV
PhilippeV

If the problem caused by transparencies or the need to alter the colors used by the extension is too difficult to implement, an alternative would be that the browser isolates the generated element by enforcing an external margin, within which the browser will diaply its own border or a half-transparent shadow, which is warrantied to be visible on top of the main document: In that case, there's no need to alter how the extension displays its own content, with its own colors, given that the extension will not have access to these margins !

PhilippeV
PhilippeV

Not that isolating a generated element will not be enough it is inserted and displayed on top of the rest of the document, without reflowing it : an extension could then remain invisible. I would suggest as well that all extension-generated elements, that belong to another document not within the same domain realm, should also be implicitly rendered by the browser with an implicit background that will (at least partly) hide the content of the main document : This could be a FORCED uniform light-gray rectangle, possibly with a more visual forced dark-gray border, with half-transparent not lower than 50%, and the generated content appearing on top of it (the browser UI preferences could allow specifiying which colors are preferable, but it should not be all white or all black, or fully transparent or fully opaque : these colors with their transparency should be visible on ALL possible backgrounds, and for this reason there should be enough contrast between the border and the background of this forced background window). The generated content will not be allowed to disply anything outside of this area : the browser will automatically clip it if this ever goes outside (even if the generated content specifies a CSS property allowing that content to overflow, this property will have no effect !). This means that the inserted element MUST be its own window in addition to have a content in its own document, even if this window is half-transparent. This will not prevent the extension to use its own colors and borders, as long as they are contrasting. Otherwise the browser should alter these colors, notably if the extension uses opaque but non-contrasting colors in such a way that this content will remain invisible.

PhilippeV
PhilippeV

Why inserting contents (even CSS or scripts) with innerHTML would be unsafe ? It will remain safe as long as the elements whose innerHTML is modified have the same origin (i.e. in the same domain realm as the domain that really inserted the outer HTML container element that was modified by the extension). To keep these innerHTML modification safe, some isolation mechanism would be added to the HTML DOM : - adding a property tracking the domain realm, and forcing extensions to use their own separate realm. - making sure that the content displayed by the inserted content (via modification of innerHTML) cannot extend outside of the specified size of the container element coming from another domain - making sure that the extension cannot modifiy the size of the the container element (so any attempt by the extension to alter the "width", "height", "left", "right", or "z-index" will be blocked if the oroginal element that was part of the document does not originate from the same domain as the extension) This means that any content added to a page by an extension will act as if it as displayed within an isolated **iframe** (with a separate parent document) if there's no secure inter-domain authorization between the domain owned by the extension, and the domain used by the main document. Being like an "iframe" (or similar to an "object" supported by a plugin or an ActiveX extension in IE), it should also have a minimum visible border, and the browser should be able to separate the content, or should allow the user to hide the additional generated content, and alert visually (with an icon in its top toolbar) the user that the displayed page contains additional generated contents. Clicking this icon should allow the user to immediately hide this content (and turning off/stopping all its running javascripts), including the possibility of reflowing the content of the main document if the element added by the extension was inserted by the extension using DOM's insertAfter() or appendChild(). As long as "innerHTML" is used within an element that the extension created itself, it is safe for the extension to modify it, including with javascript and CSS attributes or with linked CSS stylesheets and additional javascripts. Let's implement the per-domain isolation as a property of ALL elements: this is possible by changing how its parent "document" is assigned : the generated content should not be in the same document ! Simple and effective.

Michael Kassner
Michael Kassner

I guess, I don't see why reacting to issues rapidly is considered insecure. And, as I mentioned in the article, Chrome took four years to crack, whereas every other browser subverted immediately.

Adrienne Porter Felt
Adrienne Porter Felt

You are right, only the version of the website on that browser will be affected. However, it is more than the "presentation" on the user's machine. For example, take an HTTPS website. Everything on it needs to also be HTTPS for it to be secure from a network attacker. If an extension adds a HTTP .js file to this website, that website will be vulnerable to a network attacker when rendered in any browser with the extension.

Michael Kassner
Michael Kassner

But, Adrienne has been checking the comments. Hopefully, she will be able to help your concerns.

Adrienne Porter Felt
Adrienne Porter Felt

To my understanding, you are suggesting the following: 1) The browser automatically identifies untrusted content based on the origin it came from 2) The browser taint tracks the untrusted content 3) The browser isolates anything marked untrusted While this sounds like a good idea, I don't think it would be possible to enforce correctly. First, most extensions collect data from multiple origins; they aren't strictly associated with a single origin. Second, taint tracking is highly imprecise; you end up with taint explosion. Third, automatic isolation is going to break a ton of extensions because developers haven't built them with the expectation that the browser might automatically separate parts of the page into a separate origin.

Michael Kassner
Michael Kassner

I'm not qualified to answer or respond to what you pointed out. I'll get back to you as soon as I can. Thanks.

JCitizen
JCitizen

are on there at least! I didn't read the whole PDF, but I would wager that Chrome is just as vulnerable to session riding on SSL connections as the other two(FF, and IE) But Rapport does not work on Chrome. Can Chrome prevent this? Inquiring minds would like to know. :)

JCitizen
JCitizen

My version of Chrome(Dragon) is brain farting lately.

Michael Kassner
Michael Kassner

It's not a real popular subject. I have my sources looking into it. Will get back to you as soon as I learn something.

JCitizen
JCitizen

I should have taken notes. One thing for sure is it can't reach sites occasionally when the the other two can. All of them have had some trouble lately. Only problem is it could be so many variables that I can't list them all. I used to have to have AdAware installed to get my pages to download reliably and to reach sites at all sometimes; however, that Lavasoft product has really gone to pot after updating to AdAware 10, so I will not be using it anymore in the near future. I suspect that the new versions of all browsers really don't have the connection difficulties that happened not long ago. Maybe it is the HTML-5 coding, who knows? Anyway, thanks for the rep, and maybe I'll bother you later once I find out what the culprit is. I really like the fact that Dragon strips the privacy violations out of the Chrome browser, and I use Bing now, to avoid the unnecessary surveillance that Google does on their search engine. I still use Google maps but MapQuest is probably just as good, or maybe even better. Hard to avoid the handy street view though, and satellite resolution is absolutely amazing on Google now!