Hacker News Reader

Comment by capo | Hacker News Reader

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

View on HN

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...

CSP doesn't impose that restriction, but it's something we're changing at the same time:

"A package's resources are no longer available by default to external websites (as the src of an image, or a script tag)."

http://code.google.com/chrome/extensions/dev/manifestVersion...

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.

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

it needs a list of extensions to test for (see the description). so all this shows is that the list is not exhaustive.

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...

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.

I believe the Firefox behavior was already fixed. I installed SEOpen and that page didn't see that I had it installed. https://bugzilla.mozilla.org/show_bug.cgi?id=292789

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.

Wow. Awesome. Thanks for confirming

Reply on news.ycombinator.com