Devlin, any idea if there's something that can be done here or who would be a good person to look into this?

Antony's working on some similar issues, so passing to him.  I'm a little surprised the difference is so significant - we know whether or not the extension is installed, so I'd think we'd also be able to quickly determine whether or not the resource exists and is whitelisted in web_accessible_resources without bouncing around too much.

https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-isn-t-passive-browser-fingerprinting-including-passive-cookies-in-Chrome-s-threat-model-

Closing.

Let's leave this open.  For one thing, I'm not sure extension fingerprinting should be in the same boat as cookie fingerprinting et al.  For another, it means we're wasting time and resources, since we should be able to determine immediately if a resource is allowed or not, so it's a performance concern.  I've updated the bug title to reflect the latter, since it's a more definitive issue.

(feel free to remove security labels, but I'll leave that up to you)

We are presenting this attacks in the 26th USENIX Security Symposium (August 16–18, 2017 - Vancouver, Canada) as part of the paper "Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies".

We were wondering if you decided to implement some fix or mitigation to prevent this type of enumeration.

Devlin - see comment 9. 

@9 Short answer - yes, we plan to.  This is definitely something that I want us to fix, since fingerprinting user extensions should not be trivial unless the extnesion opts into it through web_accessible_resources.  There are a few different approaches we can take here, and it's a matter of prioritization.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e41fe8632d60a94200666e5eae0660bfdcd33e9

commit 0e41fe8632d60a94200666e5eae0660bfdcd33e9
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Tue Jul 11 02:13:15 2017

[Extensions] Change renderer-side web accessible resource determination

The web accessible resource determination in the renderer has an
early-out for non-existent extensions. Unfortunately, this makes it
possible to determine whether a user has a given extension installed
through timing attacks - it takes longer to make a decision about
whether to allow a resource to load when the extension is installed than
when it isn't. This can be surprisingly accurate.

Rejigger the web accessible resource determination in a few ways. Most
importantly, keep a set of loaded extensions that have any accessible
resources, and check this (rather than the full extension set) for
whether to potentially allow the load. This way, an extension with no
accessible resources and an uninstalled extension should take the same
amount of time to reach a decision, which is the desired outcome.

BUG= 709464 
BUG= 611420 

Review-Url: https://codereview.chromium.org/2958343002
Cr-Commit-Position: refs/heads/master@{#485494}

[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/chrome/renderer/extensions/chrome_extensions_renderer_client.cc
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/chrome/renderer/extensions/chrome_extensions_renderer_client.h
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/chrome/renderer/extensions/resource_request_policy.cc
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/chrome/renderer/extensions/resource_request_policy.h
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/extensions/common/manifest_handlers/webview_info.cc
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/extensions/common/manifest_handlers/webview_info.h
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/extensions/renderer/dispatcher.cc
[modify] https://crrev.com/0e41fe8632d60a94200666e5eae0660bfdcd33e9/extensions/renderer/extensions_renderer_client.h

Public paper: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/sanchez-rola

One interesting note in that paper is that Web Accessible resources are available for sites to access even when the extension is disabled from loading due to Incognito. Is this something that was/can/should be cleaned up as well?

This specific bug should be fixed (though I'm sure we have more web-accessible-resource-related issues).  I'll file a new bug for the incognito case.

Yes, it is possible to identify and access installed extensions also within the private mode. The browser can check for extensions in incognito mode, even though extensions are not allowed to access the websites.

Regarding other possible fixes:

1. Follow an extension schema that includes a random generated value in the URL: chrome-extension://[randomValue]/[path]. This random value should be modified across and during the same session and should be independent for each extension installed. For example, the browser should change it in every extension in every access. In this way, the random value cannot be used to fingerprint users.

2. Extensions should be analyzed for possible leakages before making them public to the users. Moreover, developer manuals should specifically discuss the problems that can cause the leakage of any random value generated.

> Follow an extension schema that includes a random generated value in the URL: chrome-extension://[randomValue]/[path]. This random value should be modified across and during the same session and should be independent for each extension installed. For example, the browser should change it in every extension in every access. In this way, the random value cannot be used to fingerprint users.

We've thought about this (I think it's also what FireFox does?), and it has a lot of merit.  Unfortunately, doing this would be a breaking change for two cases:
- extensions using the hard-coded url
- websites choosing to embed an extension frame that's accessible

This is something we'd like to do when we have the opportunity to make a breaking change.

> 2. Extensions should be analyzed for possible leakages before making them public to the users. Moreover, developer manuals should specifically discuss the problems that can cause the leakage of any random value generated.

This is difficult because some developers may intend for resources to be accessible to the web, and there are legitimate use cases for it.  We do document that this can allow for fingerprinting [1], but it's probably worth having some more guidance there.

[1] https://developer.chrome.com/extensions/manifest/web_accessible_resources

> We've thought about this (I think it's also what FireFox does?), and it has a lot of merit.

Yes, Firefox now follows a scheme based on URI randomization for WebExtensions in order to solve this same problem and other future similar ones. As you indicate, this is not an easy task, and they have some implementation problems that we are working to solve with them.

> This is difficult because some developers may intend for resources to be accessible to the web, and there are legitimate use cases for it.  We do document that this can allow for fingerprinting [1], but it's probably worth having some more guidance there.

Maybe recommending (possibly even enforcing at some point) the use of Shadow DOM [1], could  help evading compatibility problems and solve many future attacks, as shadow elements are invisible to queries from the main DOM.

[1] https://www.w3.org/TR/shadow-dom/

The VRP panel look at look at this bug, but I'm sorry to say declined to reward (as is usually the case for low severity bugs).  But thanks for the report!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot