User.js: FYI: web_accessible_resources & UUID [Bug 1372288, 1405971]

[Thorin-Oakenpants]

NOTE: the vetting we did on system addons and some extensions is no longer maintained here, some checks were last updated in Feb 2018. It is up to you to vet your extensions for this issue.

Update (Dec 11th 2019)

• 1372288 - still open
• 1405971 - fixed FF73+

---

If we recommend a web extension, lets make sure it doesn't leak UUIDs

@gorhill @mrdokenny @idlewan @tumpio @einaregilsson @meh @Synzvato @EFForg @kkapsner @greasemonkey @sibiantony

^^ sorry for all the @'s, hopefully this will bring it to your attention if you weren't aware, and appreciate your time if you can spare it for a quick answer, otherwise we can dig in ourselves. This issue _may_ be fixed by Mozilla, but it would be good to know if these WE's are not affected, or can be fixed to not leak - thanks

• Issue is here and some subsequent comments
• PoC
• ghacks article
• Whitepaper
• Update: 1372288 - currently access denied, will be opened up soon
  
  
  
  • Update2: 1405971
  
  

system addons

• [x] Activity Stream
• [x] Flyweb
• [x] Follow On Search
• [x] Form Autofill
• [x] Onboarding
• [x] Pocket
• [x] :x: Screenshots - requires user interaction with the WE - PoC
• [x] Shield
• [x] Web Compatibility Reporter

==> Screenshots is the only system addon affected ATM(!)
===> see .extension.getURL + path:browser/extensions/ web_accessible_resources

web extensions

• [x] CanvasBlocker - v0.4.0.2 has no web_accessible_resources
• [x] ClearURLs - v1.2 has no web_accessible_resources
• [x] Cookie Auto-Delete - v1.4.3 has no web_accessible_resources
• [x] Decentraleyes - v2.0.0beta1
  
  
  
  • web_accessible_resources are declared but are never exposed to the DOM
  
  
  • see Synzvato's comment below
  
  
• [x] Greasemonkey - v4.0 has no web_accessible_resources
• [x] Header Editor - v2.3.5 has no web_accessible_resources
• [x] HTTPS Everywhere - v2017.8.28.1337 has no web_accessible_resources
• [x] Link Cleaner - v1.5 has no web_accessible_resources - _idlewan_
• [x] Neat URL l - v2.0.5 has no web_accessible_resources
• [x] NoScript - v10.1.5.1 - has no web_accessible_resources
• [x] Request Control - v1.8.2 has no web_accessible_resources
• [x] Redirector - v3.1.0 has no web_accessible_resources
• [x] Skip Redirect - 2.2.1 has no web_accessible_resources
• [x] Smart Referer - v0.2.3 has no web_accessible_resources
• [x] ViolentMonkey - v2.8.10f - has no web_accessible_resources
• [x] uBlock Origin ¹
  
  
  
  • starting with 1.15.7b0+ web_accessible_resources are declared but are never exposed to the DOM
  
  
  • see gorhill's comment below
  
  
• [x] uMatrix ¹ - does not declare web_accessible_resources - _gorhill_

^[1] and FYI the legacy versions do not expose resource://

other web ext

• [x] Stylus - v1.1.3.1 - has no web_accessible_resources

web extensions not ready yet

• SSleuth - very unlikely to use web_accessible_resources - _sibiantony_

...

[earthlng]

The system addons that came with nightly 57 can no longer be extracted with Windows Explorer on Win7.
Do I really need to use a linux VM whenever I want to extract one of those bastards?! Does someone know of another way to extract them?
Are there maybe even plans to pack normal addons in the same way in the future?! WTH mozilla, was that really necessary?!?

[Atavic]

Greasemonkey (not sure where they are with WE)

Not yet: https://github.com/greasemonkey/greasemonkey/issues/2551
GM version 4.0 eventaully will.

[ke-d]

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources

This UUID is randomly generated for every browser instance and is not your extension's ID. This prevents websites from fingerprinting the extensions a user has installed.

FWIW, you can check if an extension has web_accessible_resources by checking its manifest.json.

[idlewan]

Does it only affect extensions that have a content script? Are extensions using exclusively a background script affected as well?

[Atavic]

It's the websites that lurk via moz-extension://

Webextentions have limited access to behind-the-scene network requests, unlike uBO/legacy which has full access to all behind-the-scene network requests.

You won't be able to see (and block) network requests made by other extensions.

See: https://github.com/gorhill/uBlock/wiki/Firefox-WebExtensions#differences-with-ubolegacy

[earthlng]

Does it only affect extensions that have a content script? Are extensions using exclusively a background script affected as well?

No, afaik only WebExtensions with web_accessible_resources

edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1372288#c19

Things that are web-accessible are presumably used by extensions in web content (not always -- sometimes they're used in an extension's own page).

[kkapsner]

CanvasBlocker uses content scripts but I do not see how it could leak the UUID.

PS: CB is not yet a WebExtension because of a missing API.

[Thorin-Oakenpants]

We'd have to re-check every new version of every WE we recommend.
Lets just wait and see what the fix will look like before we pack another shitload of work on our backs.

I understand that. This was more of a wake up, initial check and if the WE devs are aware*, they know to steer clear of it. Its not an easy fix within Firefox by the sounds of it. The ticket is now open. 3 months and not much visible activity. Suddenly (90 days later?) the whitepaper is published. The PoC (and article) probably helped sway the decision to open the ticket. And we have a flurry of comments.

I do not see this being resolved in time for ESR, let alone 57. So it would be nice to know for those if any of these WE can leak - including those not WE yet.

[sibiantony]

SSleuth has no WE yet, due to missing API.
Also, very likely it wouldn't need web_accessible_resources

[Theemim]

Does someone know of another way to extract them?

@earthlng: Let me know. https://github.com/Theemim/GeckoScratchpadSnippets/blob/master/GeckoZipReader.js

[Thorin-Oakenpants]

Thanks @sibiantony - is it this one?: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748

PS: I don't expect devs to work around this. I expect Mozilla to work out a better permissions model, but it sounds complicated.

[sibiantony]

Thanks @sibiantony - is it this one?: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
PS: I don't expect devs to work around this. I expect Mozilla to work out a better permissions model, but it sounds complicated.

@Thorin-Oakenpants Yes, that's the one.
If you meant the TLS API to be worked around, I don't think there exist a work around. Chrome doesn't support such an API either. And there is recent push for an API, thanks to EFF.

[idlewan]

In Link Cleaner's case, it doesn't inject anything into web pages and doesn't have any web_accessible_resources, so it shouldn't be affected.

[gorhill]

lets make sure it doesn't leak UUIDs

uBO does not declare web_accessible_resources (webext), and neither expose resource:// (legacy) to outside world.

[gorhill]

Same with uMatrix, no web_accessible_resources, neither resource://.

[earthlng]

@Theemim holy shit man, you're a fucking god! Thanks mate!! :+1: :+1: :+1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1352595 - it looks like, hopefully, for the time being it will only be used for nightly.
Also found this: https://github.com/mcmilk/7-Zip-zstd/issues/26 (aaaaahhhhh shit, now I've cross-referenced it again! DOH!)

[Synzvato]

Even though both Firefox Screenshots and Decentraleyes make use of the web_accessible_resources manifest key, they are not equally vulnerable. It's never good to expose secrets to untrusted code.

The proof of concept relies on the fact that Firefox Screenshots creates an anchor element with a src attribute, that points to a web accessible resource. It depends on the UUID being directly exposed within the DOM of the document in question. Decentraleyes does not write resource locations into pages.

Another way of obtaining the UUID, would be to send out an XHR, and then reading the value of the responseURL property of the corresponding XMLHttpRequest object. However, cross-origin requests will not leak the UUID either. They fail due to the absence of Access-Control-Allow-Origin headers.

Based on what I have stated above, I do not believe Decentraleyes is currently leaking out unique user identifiers. That said, of course, please do get in touch if you think I'm overlooking something.

[gorhill]

@Thorin-Oakenpants

what about uMatrix WE?

Today I prepped it up for release, but then I realized I will have to wait for Firefox 56, there is a bug that was fixed in it, which I consider crippling in Firefox 55: https://bugzilla.mozilla.org/show_bug.cgi?id=1324499.

[Synzvato]

Thanks for clarifying @Thorin-Oakenpants, and no worries! I completely understand.

PS: Thanks for all your work porting to WE

You're welcome, and I'm happy to hear you appreciate the work!

[arantius]

First, the "greasemonkey" user is a project user that no human ever logs in to (nor will ever see at-mentions of). Second the above-linked bug is just the "port user data" (from legacy->webext) issue.

Third: I have _always_ had issues with Mozilla's documentation ever since starting WebExt porting work, but this sounds like an even bigger one. Hilariously:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources

This UUID is randomly generated for every browser instance and is not your extension's ID. This prevents websites from fingerprinting the extensions a user has installed.

_If_ I've interpreted the giant thread above correctly, the true fact is that ever using web_accessible_resources creates a possible/likely privacy leak for users, but instead the documentation only talks about the benefits. If so, _that_ should be the giant/bold/red/first thing on the relevant page. Either way, something about this issue should be.

My work-in-progress Greasemonkey port _does_ use web_accessible_resources . Because there are so few/crappy UI options available to WebExtensions. Where are my chrome-free dialogs? An entire tab, or a modal-only window with a giant UUID/URL covering the entire title bar is not enough.

[Thorin-Oakenpants]

@arantius Thanks for dropping by, and thanks for your porting work. Much appreciated.

I kind of assumed (and it may not even be an issue soon if Mozilla patch quickly enough), that since ViolentMonkey didn't use any web_accessible_resources (and I know GM and VM are not the same project), that you wouldn't either.

That said, if you're not injecting these resources into the page (and clearly you aren't), I think you're fine. Certainly not your fault, and not a reason for you to change your design at all. It's a mozilla problem. The mozilla documentation wouldn't reflect the bugzilla information, it was only opened up to the public a few days ago.

Giant thread? Nah mate, that's a dwarf :) PS: I agree about the few crappy UI options.

[arantius]

Ah, but I am injecting. Into, I believe, (plain text) pages that could never observe the insertion with a script, but still.

[Thorin-Oakenpants]

Yes, I mean injecting those resources into WEB pages - not protected options/interfaces/settings/dialogs

[arantius]

https://github.com/greasemonkey/greasemonkey/blob/master/src/content/script-detect.js#L30

After mime type detection, we inject, into web content.

[gorhill]

For whatever it's worth, uBO does use an iframe for its element picker. However, the iframe has the same origin as the page, and thus no need for web_accessible_resources. The trick is to fetch the HTML in plain text from the background page from the element picker content script, then parse the response using DOMParser, and just use the result into the iframe.contentDocument through adoptNode: https://github.com/gorhill/uBlock/blob/master/src/js/scriptlets/element-picker.js#L1434. @Deathamns designed it this way originally.

[arantius]

So as long as you do not inject your own resources (and why would you?)

As said above, because limited UI options. I don't want to fire a whole tab, I can't open my own page action dialog (which would otherwise be perfect). So I'm injecting an iframe wherein I can put my small bit of UI.

Theoretically, I could re-write to replace the document with my own, which injects the original content into a frame. Not totally sure that would help, and I'd rather the platform just doesn't present this opportunity. For my usage, an extra randomized/obfuscation of the result of runtime.getURL() (so it doesn't contain this UUID) would fix it.

[kkapsner]

FYI: CanvasBlocker is a WebExtension since version 0.4.0

[Okamoi]

Apparently Tree Style Tab could be affected by this as it uses web_accessible_resources for resources/group-tab.html.

@piroor Do you see any way to get this feature to work in TST without web_accessible_resources or otherwise confirm that content will never be able to sniff resources/group-tab.html ?

[gorhill]

Update:

The manifest key web_accessible_resources is now declared in the dev build of uBO (1.15.7b0+).

This is the only solution for the following uBO's issues:

• https://github.com/gorhill/uBlock/issues/3474
• https://github.com/gorhill/uBlock/issues/2823

And this will also be the only solution to fix:

• https://github.com/gorhill/uBlock/issues/3497

Firefox

These web accessible resources are never exposed to the DOM -- hence uBO's unique extension id on Firefox cannot be seen by web pages (just as with Decentraleyes).

Chromium

uBlock Origin (or any extension) on Chromium is not assigned a unique extension id, it is assigned a static extension id, used by all installations of uBO. This means that a web page could try to fetch a resource known to be "web accessible" in order to directly find out that uBO is installed -- hence more information for fingerprinting (see http://singularity.be/public/papers/extensions.pdf).

This is essentially that leakage of information that prevented me from using web_accessible_resources to solve the above listed issues -- that is until the solution described below has been implemented.

uBO foils such information leak by requiring that the fetching of any web accessible resource be done using a secret, which secret is randomly generated at launch time. Without the secret, known only to uBO, the fetch will fail as if the resource does not exist, as if web_accessible_resources is not declared.

Demonstration of such direct detection which is foiled by uBO:

• Install AdBlock from the Chrome store: https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom
• Open a new tab to any web page, say https://news.ycombinator.com/
• Open dev console of the web page (press F12)
• Paste the following in the console and hit Enter:
  

  var xhr = new XMLHttpRequest(); xhr.open('get', 'chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/adblock-jquery-ui.custom.css'); xhr.onload = xhr.onerror = function(response) { console.log('AdBlock:', (this.status===200 ? 'DETECTED' : 'NOT detected')); }; xhr.send();

• Result if AdBlock is installed and enabled: AdBlock: DETECTED
  Result if AdBlock is not installed and enabled: AdBlock: NOT detected

However the above won't work with uBO despite it now declaring web_accessible_resources:

• Install uBO dev build from the Chrome store: https://chrome.google.com/webstore/detail/ublock-origin-dev-build/cgbcahbpdhpcegmbfconppldiemgcoii
• Open a new tab to any web page, say https://news.ycombinator.com/
• Open dev console of the web page (press F12)
• Paste the following in the console and hit Enter:
  

  var xhr = new XMLHttpRequest(); xhr.open('get', 'chrome-extension://cgbcahbpdhpcegmbfconppldiemgcoii/web_accessible_resources/to-import.txt'); xhr.onload = xhr.onerror = function(response) { console.log('uBO:', (this.status===200 ? 'DETECTED' : 'NOT detected')); }; xhr.send();

• Result if uBO dev build is installed and enabled: uBO: NOT detected
  Result if uBO dev build is not installed and enabled: uBO: NOT detected

---

Addendum (2018-02-17):

I experimented further with the case of XMLHttpRequest, which can expose the URL resulting from redirection (through responseURL, as noted by @Synzvato above), and I confirm that redirecting to "web accessible resources" for network requests of type xmlhttprequest will expose the extension id on both Firefox and Chromium.

As a result, I modified the code such that no redirection to web accessible resources will take place when dealing with xmlhttprequest -- uBO will fall back to use data: URI in such case (uBO 1.15.7b2+). Redirecting to data: URI is currently broken on Firefox Nightly, but this is being addressed in https://bugzilla.mozilla.org/show_bug.cgi?id=1434357 (there is only a very few instances of such filter in uBO).

[earthlng]

Thanks for the detailed info @gorhill ! 👍