Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: web_accessible_resources & UUID [Bug 1372288, 1405971] #227

Closed
Thorin-Oakenpants opened this issue Aug 30, 2017 · 51 comments

Comments

Projects
None yet
@Thorin-Oakenpants
Copy link
Member

commented Aug 30, 2017

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: also 1405971


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

system addons

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

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

web extensions

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

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

other web ext

  • 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

This comment has been minimized.

Copy link
Member

commented Aug 30, 2017

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

This comment has been minimized.

Copy link

commented Aug 30, 2017

Greasemonkey (not sure where they are with WE)

Not yet: greasemonkey/greasemonkey#2551
GM version 4.0 eventaully will.

@mrdokenny

This comment has been minimized.

Copy link

commented Aug 30, 2017

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

This comment has been minimized.

Copy link

commented Aug 30, 2017

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

@Atavic

This comment has been minimized.

Copy link

commented Aug 30, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 30, 2017

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

This comment has been minimized.

Copy link

commented Aug 30, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

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.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

3 months and not much visible activity

Actually, I should say 3 months (since the UUID leak issue was reported, not the previous timing attack issue from last year) and no activity (some tag dancing sec-low etc, one comment) .. aaaaand suddenly we have traction...

so FUKYEAH™ that PoC did something

Edit:

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

do you think this should be considered a blocker for the Firefox 57 release? It seems like a pretty serious slip up.

Well sheesh. Imagine if no one had said anything... so glad now about this being publicnow. Big ups to the whitepaper peeps

@sibiantony

This comment has been minimized.

Copy link

commented Aug 31, 2017

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

@Theemim

This comment has been minimized.

Copy link
Collaborator

commented Aug 31, 2017

Does someone know of another way to extract them?

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

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2017

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

@idlewan see this reddit thread .. maybe earthling can explain it. My understanding is the same as yours - content must be injected

@sibiantony

This comment has been minimized.

Copy link

commented Aug 31, 2017

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

This comment has been minimized.

Copy link

commented Aug 31, 2017

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

This comment has been minimized.

Copy link

commented Aug 31, 2017

lets make sure it doesn't leak UUIDs

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

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2017

@idlewan Thanks. I already cleared Links Cleaner and checked your manifest
@gorhill - Thanks 💋 .. what about uMatrix WE?

@gorhill

This comment has been minimized.

Copy link

commented Aug 31, 2017

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

@earthlng

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

@Theemim holy shit man, you're a fucking god! Thanks mate!! 👍 👍 👍
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: mcmilk/7-Zip-zstd#26 (aaaaahhhhh shit, now I've cross-referenced it again! DOH!)

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2017

I've added Stylus (becuz) and VM (becuz GM ain't WE yet) to the list. I know they are not on our Wiki. Scream out if you can think of anything else

@Synzvato

This comment has been minimized.

Copy link

commented Sep 1, 2017

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.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Sep 1, 2017

Thanks for the info @Synzvato

Sorry if that looks scary. I've changed it to a By no means am I denigrating any extensions etc, and by their very nature, some extensions are going to be susceptible. It's all a little over my head to be honest. The problem and fix lies with Mozilla. The is a much fairer reflection. Sorry about that. Hopefully this is an exercise in futility, and Mozilla comes up with a workable solution.

PS: Thanks for all your work porting to WE

@gorhill

This comment has been minimized.

Copy link

commented Sep 1, 2017

@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

This comment has been minimized.

Copy link

commented Sep 2, 2017

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!

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2017

@earthlng 💋 for checking the system addons 👍

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2017

Thanks everyone..

Conclusion:

Everything looks great for WE we recommend - if there are no web accessible resources, it cannot leak! Even Stylus (popular) and VM (alternative to GM). Proven devs, quality work, and of those not yet ported, I cannot see them providing any either - NoScipt might warrant a check.

@Synzvato has talked about Decentraleyes: over my head a bit - it's not using any script injection (probably worded that wrong), so it shouldn't/can't be detected

The chances of anyone out there running scripts for this is slim to none right now, I do not think anything we use is leaky, and Mozilla will issue a patch in time (although the flurry of comments has now DIED to a slithering crawl - booo!).

Task completed AFAIC and time to slap a bug label on it

@Thorin-Oakenpants Thorin-Oakenpants added firefox bug and removed task labels Sep 3, 2017

@arantius

This comment has been minimized.

Copy link

commented Sep 3, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2017

I have to admit, I stopped coding over a decade ago (and not in any web technologies), and some of this is a little over my head. @earthlng understands this 100% 200% better than me, so I'll let him follow up and clarify this.

As far as I know:
ViolentMonkey injects (it has too right, otherwise it cannot control/change anything, right?). Greasemonkey does too. Screenshots does as well. Screenshots injects its own resources, and it is the resource path that is traced, revealing the UUID. So as long as you do not inject your own resources (and why would you?) then I think the UUID is not leaked.

^^ BUT i am NOT knowledgeable enough on this, and I may have misunderstood it.

OOh .. there's gorhill .. he knows lots :)

@arantius

This comment has been minimized.

Copy link

commented Sep 13, 2017

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.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2017

Thanks @arantius ,, as far as I'm concerned, this is not your problem - it is Mozilla's. Please don't waste your time and resources on it too much

PS: Thanks ever so much for porting GM. Any idea of when it might land? I'm holding out for it - I do not want to go VM, and refuse to even look at TM. Cheers :)

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Sep 30, 2017

@rekixex ... Neat URL has no web_accessible_resources in its manifest.json - added to the first post, thanks

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Oct 2, 2017

  • Skip Redirect - 2.2.1 has no web_accessible_resources (added to first post)
@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2017

FYI: Updated versions (updated in first post)

  • Smart Referer - v0.2.3 has no web_accessible_resources
  • ViolentMonkey - v2.8.10f - has no web_accessible_resources

Smart Referer AMO is now the WebExtension version
VM finally had an update after AMO got a wriggle on - also VM is now listed on the Wiki Extensions page, and I'm using it and ditched GM

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2017

added to first post: * Update2: 1405971

@kkapsner

This comment has been minimized.

Copy link

commented Nov 10, 2017

FYI: CanvasBlocker is a WebExtension since version 0.4.0

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2017

^^ good point .. I'll also move greasemonkey up to the right section

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2017

woo .. GM web extension has no web accessible resources

@Thorin-Oakenpants Thorin-Oakenpants changed the title vetting time: WE & contentaccesible & manifest & UUID vetting time: WE & contentaccesible & manifest & UUID [Bug 1372288] Nov 30, 2017

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Dec 2, 2017

NoScript v10.x checked and updated in first post

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Dec 8, 2017

Header Editor - v2.3.5 checked and added in first post

@Okamoi

This comment has been minimized.

Copy link

commented Dec 11, 2017

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 ?

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Dec 17, 2017

update: - added: ClearURLs - v1.2 has no web_accessible_resources

@Thorin-Oakenpants Thorin-Oakenpants changed the title vetting time: WE & contentaccesible & manifest & UUID [Bug 1372288] vetting time: WE & web_accessible_resources & UUID [Bug 1372288] Dec 25, 2017

@gorhill

This comment has been minimized.

Copy link

commented Feb 16, 2018

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:

And this will also be the only solution to fix:

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

This comment has been minimized.

Copy link
Member

commented Feb 16, 2018

Thanks for the detailed info @gorhill ! 👍

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Feb 16, 2018

Yes, @gorhill thank you very much for the detailed info 💋 I will update the first post

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Feb 17, 2018

from gorhill's comment addendum three posts up

as noted by @Synzvato above

  • Gorhil thanks for blocking that responseURL + xmlhttprequest leak.
  • Synzvato I removed the red question mark for Decentraleyes in the first post since you clearly have this covered

@Thorin-Oakenpants Thorin-Oakenpants changed the title vetting time: WE & web_accessible_resources & UUID [Bug 1372288] FYI: web_accessible_resources & UUID [Bug 1372288] Sep 19, 2018

@Thorin-Oakenpants Thorin-Oakenpants changed the title FYI: web_accessible_resources & UUID [Bug 1372288] FYI: web_accessible_resources & UUID [Bug 1372288, 1405971] Nov 17, 2018

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Dec 9, 2018

might as well close this one as well, it's been 15 months and it's not a simple fix by the sounds of it (needs jesus!!). At least we vetted our extensions at the time, and spoke to a bunch of awesome devs etc. Something to always be mindful of sigh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.