

Web pages can sniff to see what Chrome extensions you have installed - benmccann
http://code.google.com/p/chromium/issues/detail?id=118693&thanks=118693&ts=1331937415

======
abarth
This is fixed in manifest_version 2:

"A package's resources are no longer available by default to external websites
(as the src of an image, or a script tag). If you want a website to be able to
load a resource contained in your package, you'll need to explicitly whitelist
it via the web_accessible_resources manifest attribute."

[http://code.google.com/chrome/extensions/dev/manifestVersion...](http://code.google.com/chrome/extensions/dev/manifestVersion.html)

See <[http://blog.chromium.org/2012/02/more-secure-extensions-
by-d...](http://blog.chromium.org/2012/02/more-secure-extensions-by-
default.html>); for information about other security improvements in
manifest_version 2.

~~~
aboodman
manifest version 2 is not backward compatible, so most extensions should not
update yet. When Chrome 18 is deployed to the stable channel, we will update
the docs and begin slowly encouraging developers to transition.

In the shorter term, developers who want to prevent their extensions from
being trivially detected can use the web_accessible_resources property
instead:
[http://code.google.com/chrome/extensions/dev/manifest.html#w...](http://code.google.com/chrome/extensions/dev/manifest.html#web_accessible_resources).
This property is available in Chrome 19 and higher and is ignored in older
versions.

------
ig1
Chrome extension are probably a major source of untapped security holes. No-
one really considers security when writing them and they often take arbitrary
input (in the form of webpages they're processing) without validation.

It wouldn't surprise me if a lot of them have javascript injection
vulnerabilities that allow for privilege escalation.

~~~
jQueryIsAwesome
I am more concern with the overconfidence of some user over their
extensions/updates; a extension with many users can suddenly include something
like:

    
    
        $('.email, input[type=password]').val(send_to_database)

~~~
JohnQPasserby
why would the attacker setting the password field be a problem

~~~
nitrogen
That looks like it retrieves the value of any element with the class name of
.email and any password input (i.e. harvesting e-mail addresses and
passwords).

<http://api.jquery.com/val/#val2>

------
sses
What are the security implications? A malicious page can attempt to exploit a
buggy extension whether it knows the extension is present or not.

~~~
chrisacky
Implications....

Lets assume that malicious page A, can figure out what extensions a user is
running.

They figure out that some user has extensions, A, B, C and D.

Extension D is actually an email client extension which is terribly coded. The
victim uses the very same email provider for all of his mail. The malicious
website figures out that he can safely send POSTs to the mail provider through
this extension that will alter the victims mails filter.

So the malicious website tells it to forward all email received to
`foobar@email.com`. Additionally, any email from @super-bank.com should be
deleted. And any emails from @godaddy.com should also be deleted after it gets
forwarded to the malicious user.

Now, the malicious user requests new passwords on Godaddy for example and
receives the passwords then he transfers all of his domains out. Win for the
malicious website.

~~~
simonbrown
It can attempt to do that anyway. Whether it knows extension D is installed or
not.

------
cowkingdeluxe
Can't you do this in Firefox and other browsers too? I thought that was one of
the reasons why your browser can be uniquely identified.

~~~
capo
Yup: <https://panopticlick.eff.org/> Also: <http://ha.ckers.org/weird/firefox-
extentions.html>

~~~
azakai
Those look very limited in their ability to detect addons.

------
arpitnext
[http://blog.arpitnext.com/2011/08/chrome-extension-
awesome-s...](http://blog.arpitnext.com/2011/08/chrome-extension-awesome-
screenshot.html)

------
alanh
Also somewhat annoyingly (and not just limited to Chrome), extensions &
bookmarklets can show up if you save or archive the web page for some reason.

------
capo
That's why they're transitioning to "manifest_version 2" (CSP):
[http://blog.chromium.org/2012/02/more-secure-extensions-
by-d...](http://blog.chromium.org/2012/02/more-secure-extensions-by-
default.html)

~~~
mbrubeck
This seems like a great way to limit the damage from a security hole in an
extension. (It prevents web content from loading arbitrary code and running it
with the extension's privileges.)

But it doesn't appear to address the sniffing issue at all.

UPDATE: Sniffing _is_ prevented in manifest_version 2, but not by the CSP. See
my reply to andrewcooke below for more details.

~~~
capo
Interestingly the "enumerator" tool doesn't list all my extensions, and it
lists even less when testing on the machine running the beta channel (18).

Similar behavior Firefox exhibits regarding:
<http://ha.ckers.org/weird/firefox-extentions.html>

~~~
mbrubeck
The enumerate demo uses a list of popular extensions; it will only detect
extensions on the list, though any Chrome extension can be added to the list
trivially. See the list here: [https://github.com/koto/blog-kotowicz-net-
examples/blob/mast...](https://github.com/koto/blog-kotowicz-net-
examples/blob/master/chrome-addons/addons.json)

The Firefox version is a little more interesting; it relies on knowing a
specific "chrome:" URI exposed by each extension, so it takes a small amount
of work to add new extensions to the list. And I believe that many newer
Firefox extensions do not expose any chrome: URIs, so this technique might not
work for all Firefox extensions.

------
exaakax
It was through the Flash extension that Chrome was hacked in 5 minutes in a
recent Pwn2own contest

~~~
icebraining
Flash is actually a plugin, not an extension. The difference is that plugins
are designed to render content that the browser cannot, while extensions
simply add new features to the browser or change the behavior of existing
ones.

