Extensions security

[Ted]

Hi All,

I've just created my first Chrome Extension, and can say that from
developer perspective the API and whole architecture is really great
to work with.

Although I really like working with extensions, the power that
extension developer has really scares me. This subject was already
discussed here (http://groups.google.com/group/chromium-extensions/
browse_thread/thread/ec54f542447cba05) but I found that the thread
died more then year ago without any significant conclusions.

I'm not a security expert nor really experienced extension developer,
so if someone can calm my worries and point me where I'm wrong, it
will be highly appreciated :)

So, what worries me:

1. Content scripts + Cross Origin XHR

It is really easy to implement extension that will be also key logger.
It's already covered by thread I've mentioned - let us assume that
we've got extension that will be advertised as the one that allows you
to grab any image from page and send it to particular service one use
(flickr whatever). It's just example, but with this example, it will
be easy to convince user that this extension needs privilege to:
inject content script to every page, make http requests. I'm sure
there are loads of other ways to advertise malicious extension using
cover of really useful one.

Additionally, since such a extension has ability to edit DOM, it
allows phishing to reach totally new level. Let say, that we're using
on-line banking, that has 3 layered security (it's most popular
approach in PL) - to make a payment/transaction, user must provide:
user Id, password and random token either generated, or send via text
message to defined mobile phone no. It's really not that hard to
imagine attack on given bank system, that will be shipped using chrome
extension. First extension will steal login + passwd, and then goes
phsing. After successful log on, extension can monitor user actions by
parsing DOM, when it will detect that user just reached form asking
for token, it can steal the token, render page that will mimic
successful transaction and send all credentials needed to clear given
account to the criminal.

It's most serious danger I could imagine, and I've got this idea after
2 days of working with extensions, and I'm not an expert in either
security/social engineering/chrome extensions!

One question here - how in case of extensions 'same origin policy' is
interpreted - extension can make XHRs to the host from which it was
downloaded? If so, it's even more dangerous.

2. Partial extensions isolation

Isolation of extensions is really phony. Using message passing and
then DOM events (as suggested in extensions tutorial) extensions can
communicate with each other. This allows even more sophisticated
attack. Let say that there is extension A that needs 'only' access to
DOM of any page, but doesn't need/perform XHR. And, let us have
extension B which claims that need access just to one/two kind of
popular URLs + XHR. Now extension A steals data, opens new page to
which extension B can inject script, exchange data with B using DOM
events and closes window directly afterwards.

Short update - I've found that it's even easier, as extensions can
communicate between each other without any restrictions.

3. Other Deployment Options

Malicious developer may install chrome extension that can do
everything, without asking for permission, using other deployments
options. Let say that such a criminal, prepares tiny freeware, useful
application that doesn't contain any malicious code, thus won't be
detected by antivirus software. Installer of such a application may in
turn install any chrome extension using either windows registry or
preferences file. This extension can do anything and user won't even
notice it, until he/she goes to the chrome://extensions.

It all may sound paranoid, but I'm thinking here mostly about users
like my mother who can barely differentiate internet from browser and
so on. I'm sure that there are loads of such a users 'out there'.
Because of that I think that the developers shouldn't rely on user's
knowledge.

Some ideas on how to improve a bit:

1. Create URL's black list. User should be able to define set of URLs
into which content script will NEVER have access. I think also that
such a list should have initial entries filled by chrome developers,
containing well known, crucial services, like on-line banks, most
popular e-mail providers, shops and so on. Additionally it would be
great if web service developers/managers could post request to block
extensions on their site. Of course, user can edit this list and e.g.
remove entries he/she think that can use extension.

2. Ask user whether he/she wants to install or load extension that was
installed using 'Other Deployment Options'

3. Maybe think about more fine grained sandboxing, using flashplayer
as a source. In flash for example, various actions might be performed
only triggered by user event. It's really tough one.


Hope this will make someone to think about extensions security a bit,
also thanks in advance for any calming info ;)

Regards,
Ted

[Erik Kay]

Hi Ted,

Thanks for your thoughtful feedback.  Since similar questions come up periodically, I'll try to provide a fairly thorough answer.

The first thing that I'd like to point you at is a little background on Chrome Extension Security:

http://blog.chromium.org/2009/12/security-in-depth-extension-system.html

http://www.youtube.com/watch?v=DO-nzPqhdXw

http://webblaze.cs.berkeley.edu/2010/secureextensions/

One thing to understand is that there are two basic threat models that our security system was designed to handle:

- benign, but buggy extensions

- malicious extensions

These threats are quite different in nature and thus have very different protection mechanisms.

Most of our security features are aimed at the first case:  permissions, multi-process, isolated world, autoupdate.  To understand the threat model a bit more, take a look at this paper:

http://www.usenix.org/event/woot09/tech/full_papers/adida.pdf

This is the main purpose of isolated worlds.  The code from a well-intentioned developer is isolated from potentially hostile pages on the web, thus making it much harder for a random page on the net to target an extension.  As you point out below, it offers no protection against an actively malicious developer.  It was never intended to do so.  Since you were focused on the malicious developer case, I won't go into this threat model more, but there's a lot to talk about on that topic.

The tricky part about malicious extensions is that it's impossible to differentiate between useful but powerful extensions (e.g. a password manager) and a roughly equivalent malicious extension (e.g. a password stealer).  Once you add powerful capabilities to a platform, you enable both powerful and dangerous side-by-side.  So you have a choice, either limit the capabilities, or come up with mitigations.  Let me walk through some of what we have in place today.  These mitigations will never be perfect, and some are designed to work after the fact:

- social indicators in the webstore - Number of installs and user reviews work as an indicator for developer trustworthiness

- permissions warnings - Useful for knowledgeable users to understand roughly what the risks are for using an extension.  Knowledgeable users share this information via reviews in the store.

- a simple mechanism for users to report suspicious extension behavior and a fast review process for these reports

- dangerous download warnings - when you install an extension from a site other than the chrome web store, you get a similar install flow as if you were installing a random .exe from the web

- developer fee for signing up to publish to the web store - this makes it more difficult for a malicious developer to create many accounts to upload variants of bad extensions, and makes it easier for us to take down all of the extensions by a known malicious author

- verified website owner indicator - some protection against phishing by verifying that the author is the owner of the indicated website

- extension blacklist - the ability for us to mark an extension as malware which prevents it from being installed by new users and uninstalls it from users who have previously installed it

- enterprise policies - enterprises can limit whether users can install extensions or which extensions they can install

- file:// host permissions require explicit user opt-in

- incognito permissions require explicit user opt-in

- automated scanning for dangerous payloads at store upload time

We're also continuing to look for ways to improve our security.  Some upcoming improvements:

(you'll note that two of the ideas you suggested are things we've been planning for a while now)

- a user/enterprise host blacklist that makes certain sites off-limits to content scripts by default (with user-opt in)

- optional permissions - allowing developers to move non-critical permissions to an optional list that can be selectively enabled/disabled by a user

- host permissions tied to user gestures - so that an extension can have access to the current tab when the user clicks a button, not just any host at any time

- a way to disable non-gallery installs altogether

- an extension auditing feature for power users

- new APIs and features that reduce the need for content scripts (infobars, sidebars, keyboard shortcuts, mouse gestures, etc.)

- enabling Content Security Policies for extensions (eventually on by default)

- requiring strict mode for javascript by default

- a security "lint" tool for extensions at upload time to the store - identifying common bugs or risky behavior in extension code

- continuing to add ways to make permissions more granular so that extensions need fewer dangerous permissions to do their job

There are many other things we're considering, but hopefully this gives you some indication of how we think about this issue.  As I said, given that we want to make extensions useful and capable, it's impossible to prevent people from also using them to write malicious things.  The above mitigations will never be able to prevent a determined attacker with good social engineering.  Our hope is to minimize the number of users affected and the duration of any attack, and to give informed users ways to minimize the risks.

Erik

p.s. One other point you brought up is related to extensions installed by a locally running executable.  In general, once an executable is running on your local machine, the fact that it can modify Chrome is the least of your concerns.  Further, if this is being done maliciously, there's no way for us to prevent them from doing so silently and circumventing any mechanisms we put in place to notify users.  They can always modify data files in a way that would make it impossible for us to differentiate between whether you installed it yourself or whether it was installed externally.  You can see some discussion of this in the following bug: crbug.com/83587

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.