Detection of uBlock Origin in Chrome via web_accessible_resource timing side channel

[arxenix]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uBlockOrigin
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

It is easily possible to detect the presence of uBlock Origin in chrome by sending requests to chrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/web_accessible_resources/noop.html and measuring how long the request takes.

I don't know what uBlock Origin uses web_accessible_resources for, but if possible, they should be removed.

A specific URL where the issue occurs

POC Source Repo: https://github.com/arxenix/chrome-ublock-detection

direct POC link: https://arxenix.github.io/chrome-ublock-detection/

Steps to Reproduce

see POC link

Expected behavior:

A website should not be able to determine that uBlock origin is installed.

Actual behavior:

A website is able to determine that uBlock origin is installed.

Your environment

• uBlock Origin version: 1.34.0 (latest)
• Browser Name and version: Chrome 90.0.4430.93
• Operating System and version: Windows 20H2 19402.928

[arxenix]

this attack does not seem to be possible in ff because it randomizes the extension ID for web_accessible_resources.

If you would like PoC's taken down, please let me know.

[uBlock-user]

https://github.com/gorhill/uBlock/tree/master/src/web_accessible_resources#readme

[arxenix]

https://github.com/gorhill/uBlock/tree/master/src/web_accessible_resources#readme

this technique circumvents the secret token (sort of?). you cannot read files from web_accessible_resources because you do not have the token, but you can detect the files presence using timing, thereby confirming the presence of uBlock origin

[gorhill]

It's not something that can be fixed, it's a browser-specific framework issue, best to report to Chromium devs.

[arxenix]

@gorhill yeah that's what i suspected 😞. are the web_accessible_resources required for uBlock to function (what exactly does it use them for?)

the request is being blocked as soon as possible w/ chrome's APIs, correct?

[arxenix]

a "hacky" solution which might solve the problem could be to apply this guard filter

 browser.webRequest.onBeforeRequest.addListener(
        guard,
        {
            urls: [ root + 'web_accessible_resources/*' ]
        },
        [ 'blocking' ]
    );

to every request rather than just root + 'web_accessible_resources/*', but I agree that this is something that should be fixed on chromium's end instead.

[liamengland1]

It would be nice to know if you filed a bug on the chromium tracker.

[gorhill]

I was on my phone when I answered yesterday, I had assumed your proof of concept worked.

Now I can try it, and using Chromium 90.0.4430.93 (linux), I get:

My bad, disregard that I could not reproduce on my side, I was silly and I forgot that my version of uBO was a locally installed one, not the one from the Chrome store. The PoC does work:

uBlock detected.
460/500 requests were slower
avg ublock: 0.5691600008867681
avg fake: 0.3856499994872138

---

But assuming you make it reliable somehow, here are things to consider:

• Fingerprint libraries can already identify most blockers by using bait resources/elements to trigger filters specific to the blockers
• Fingerprint libraries are blocked by default in uBO, as reported by the community
• uBO has tens of millions of users (as reported in Chrome store)

The goal is not to make it impossible to JS libraries to identify uBO specifically is present -- that itself is impossible -- the goal is to make it difficult enough.

By Chromium extension framework design, sites are able to peek at an extension's web_accessible_resources folder in the package[1], consider I made it more difficult to do so by requiring the use of a single-use token (though as said above, the POC currently fails on my side).

---

[1] There might already be an issue opened in Chromium tracker for that.

[gorhill]

a "hacky" solution which might solve the problem could be to apply this guard filter [...] to every request rather than just root + 'web_accessible_resources/*'

That can't work because an extension is not allowed to listen to another extension'sweb_accessible_resources fetches.

[stephenhawk8054]

@gorhill Sorry, if I'm not wrong, chromium does have use_dynamic_url option in the manifest to address this?