"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."
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.... This property is available in Chrome 19 and higher and is ignored in older versions.
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.
Researchers at UC Berkeley studied this exact question. About 40% of extensions contain at least one injection vulnerability. Some really popular extensions were vulnerable -- even a couple Google authored ones.
Starting with Chrome 18, extensions will be subject to
a CSP that enforces some of these bans [13]. Our study
partially motivated their decision to adopt the bans [1],
although the policy that they adopted is slightly stricter
than our recommendations. The mandatory policy in
Chrome 18 will ban HTTP scripts in core extensions, inline scripts, and dynamic code generation. Due to technical limitations, they are not adopting a ban on adding
HTTP scripts to HTTPS websites. The policy will remove all of the core extension vulnerabilities that we
found. The only extensions that the policy will permanently break are the two extensions that rely on eval.
The paper is mistaken in that these changes are actually coming with the manifest_version=2 property that is optional starting with Chrome 18, not required. However, we will be slowly transitioning the ecosystem over to this version and will eventually require it.
We've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:
script-src 'self'; object-src 'self'
This policy imposes the following restrictions on extensions:
Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>.
Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead.
Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts.
The CSP changes primarily address the XSS issue in extensions. Many of these vulnerabilities come because extension developers run code from untrusted sources. CSP blocks that in most cases.
Separately, we implemented web_accessible_resources. That addresses the sniffing issues.
fair enough, but i'm not sure i'd agree. it's much easier to detect a malicious extension than to detect a page you are about to visit is going to exploit the negligence of one of the extensions.
firstly, the extension source is available meaning it's open to review and criticism. more so, the concern here is even if i am careful about the extensions i install, i am still vulnerable.
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).
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.
Firefox divides browser add-ons into several categories (as do other browsers, but I'm most familiar with the Firefox terminology), including:
* Extensions
* Plug-ins
* Search engines
* Themes
"Plug-ins" are a particular type of add-on registered to handle specific media types in <embed> and <object> elements. There are a relatively small number of common plug-ins, including Flash, Java, Silverlight, and Quicktime. They are designed to be exposed to web content, so web pages can easily test for them. The EFF Panopticlick demo uses plug-in sniffing as part of its fingerprinting.
"Extensions" are add-ons that use browser APIs to modify the behavior of the browser application. There are a huge variety of popular extensions, including Adblock Plus, Greasemonkey, Chrome To Phone, Stylish, Tree Style Tabs, etc. In general, a web page can detect an extension only if it modifies the pages or takes some other action to expose itself to scripts on the page. However, this bug report and blog post demonstrate a way for a web page to detect a Chrome extension even if it does not take such actions. And one of capo's links in this thread demonstrates a similar method that works for many Firefox extensions.
Plug-in sniffing is possible in all browsers that support plug-ins, and there's no simple fix without breaking web compatibility. Extension sniffing depends on both the browser and the extension, and there are reasonable ways it could be fixed or mitigated.
Interesting. So CSP will stop web pages from loading content located at the chrome-extension:// scheme? From the docs it seems that it will stop the extension from loading certain resources, but it's not clear that it will stop the page from loading extension resources.
http://code.google.com/chrome/extensions/trunk/contentSecuri...
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.
it says "Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>."
to me that sounds like it will block this sniffing, which works by loading code from outside of the extension package.
The new default CSP stops pages/scripts inside the extension from loading resources from outside the extension. It doesn't stop pages/scripts outside the extension loading resources from inside the extension.
And besides that, the default CSP does not include a "connect-src" policy so it does not place any limits at all on XMLHttpRequest, which is the method used by the sniffing demo. It includes only "script-src" and "object-src" policies, which affect only the src attributes of <script> and <object> elements.
(If someone here has an example Chrome extension that uses manifest_version 2 or an explicit content_security_policy, then we can test this directly...)
---
UPDATE: I tested this locally with a bare-bones extension, and adding "manifest_version: 2" does prevent sniffing in Chrome 18.
I also tried adding { "content_security_policy": "script-src 'self'; object-src 'self'" } explicitly to an extension without bumping the manifest_version. This did not prevent sniffing. So it looks like there's no way to prevent sniffing in extensions for Chrome 17 and older.
So while it's not directly related to the new default CSP, it looks like the sniffing issue is in fact addressed in Chrome 18 for extensions that opt in to the new manifest_version.
UPDATE 2: See abarth's top-level comment for the details of the fix.
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.
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.
"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...
See <http://blog.chromium.org/2012/02/more-secure-extensions-by-d...; for information about other security improvements in manifest_version 2.