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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

sticky: fixed/signed legacy addons not on AMO: No Resource URI Leak etc #191

Closed
earthlng opened this issue Aug 7, 2017 · 34 comments

Comments

Projects
None yet
10 participants
@earthlng
Copy link
Member

commented Aug 7, 2017

AMO no longer allows the uploading of legacy addons. Unless you are the original developer, you cannot even upload a fixed clone. This is an issue - ESR will be on extended life support for almost a year (until 2018-06-26 I believe).

馃敻 Fixed add-ons


@earthlng says:

FF55 seems to break SDK addons that use a relative path to load content scripts.
Using the absolute path fixes the problem in FF55+ and also works in older versions.

Until the addon devs release an update or someone @ mozilla fixes whatever caused the addon to break, you can use this copy - fixed by Yours truly xD

You need to configure your settings again because I had to change the addon ID.

I also removed the console output for caught exceptions (annoying and useless for end-users) + changed the name to make it easier to distinguish.
You can keep the original installed (disabled!) and wait for an official update.

download

Resource Test Page: https://browserleaks.com/firefox

@earthlng earthlng referenced this issue Aug 7, 2017

Closed

sticky: add-ons #12

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 8, 2017

Added info to the wiki

@Thorin-Oakenpants Thorin-Oakenpants changed the title [hotfix] No Resource URI Leak sticky: fixed/signed legacy addons not on AMO: No Resource URI Leak etc Aug 8, 2017

@AdKiller

This comment has been minimized.

Copy link

commented Aug 8, 2017

Thanks for fixing No Resource URI Leak (clone).

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2017

Great, I didn't read nor include the COPYING file. I hope I can count on you with my legal fees.

@ghost

This comment has been minimized.

Copy link

commented Aug 9, 2017

@earthlng added

fixed by Yours truly xD

and the audience replied : Bravo, thank you, merci, danke sch枚n :)

This sticky topic is and will become a reference for FF55+ users. Already mentioned on Ghacks.

Using the absolute path fixes the problem in FF55+ and also works in older versions.

Here on FF ESR 52 I have no issue with the original No Resource URI Leak 1.1.0 but is it advised to nevertheless update this add-on to its 1.1.1 version proposed here?

Many thanks, earthlng.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 9, 2017

Sure, send the bill to Atavic .. I have promoted him to Secretary of Finance

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2017

and the audience replied : Bravo, thank you, merci, danke sch枚n :)

You're welcome, 脿 votre service, gern geschehen :)

Here on FF ESR 52 I have no issue with the original No Resource URI Leak 1.1.0 but is it advised to nevertheless update this add-on to its 1.1.1 version proposed here?

No. If the console output for caught exceptions in the original version bother you then you can use my version instead. Apart from that they work identical.

@ghost

This comment has been minimized.

Copy link

commented Aug 9, 2017

I've nevertheless updated No Resource URI Leak 1.1.0 to No Resource URI Leak (clone) 1.1.1 even if not required with pre-FF55 for the sake of code improvement. "It's not because it works that you shouldn't improve it"

@publicarray

This comment has been minimized.

Copy link
Collaborator

commented Aug 17, 2017

@rekixex You can have a look at https://browserleaks.com/firefox it shows you what is leaked. I don't think the locale matters in any way.

Can websites enumerate installed legacy add-ons / web extensions, or even access add-on preferences?

Checkout https://thehackerblog.com/addon_scanner.

More fingerprinting and other test sites are in the wiki

P.S. Could you please stop spamming my email? Much appreciated.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 17, 2017

[browserleaks] it shows you what is leaked

^^ TBH, this shows you a few things that can be leaked, focusing on FF/TBB internals

Resource:// URIs declared content-accessible in manifests LEAK even with the proposed tor uplift patch (otherwise shit breaks), in fact they are "Moving resources that need to be exposed to web content to locations that are marked as content-accessible" - this so that ALL OTHER resources are off limits. This simplifies it. I am not a dev, I do not think this manifest is required/used in Web Ext.

There are other ways to detect addons - notably Adblockers, although TBH, a lot of them are generic and do not actually detect the extension, just the affect, AFAIK. I am sometimes accused of having AdBlock Plus, which I don't.

Preferences can't be accessed directly, only induced - if they could be directly read, we'd be FP'able to the nth degree! [Note: this is what Sherlock Holmes almost always does - not deduction as he claims so often - tidbit included for crssi to help my beer funds ]

@crssi

This comment has been minimized.

Copy link
Collaborator

commented Aug 17, 2017

:)

Unfortunately I have understood it all. But to fill your jar, I can easily find some stupid question for beer sake?

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 17, 2017

I do not think this manifest is required/used in Web Ext.

It is used in WE's as well: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension#Web_accessible_resources

Preferences can't be accessed directly, only induced

atm all the default preferences files in FF can be accessed and read directly.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 17, 2017

atm all the default preferences files in FF can be accessed and read directly.

Well, then that creates what? 10 distinct default pref sets? - Mac, Windows, Mobile, Focus, Various Linux? I can see default prefs giving away OS, build even. So loads of info just on defaults. OS, versions, builds... wouldn't be hard to work out combos unique to each one.

Out of curiosity .. how is this accessible ATM ? resource leak?

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 17, 2017

disable the addon and load https://browserleaks.com/firefox, then click on any of the filenames it detected and it will list you all the prefs in that file. OS and FF version can easily be detected that way f.e. check for a single pref that's new in 55 or a single pref that has a unique value in Mac or Linux, etc.

how is this accessible ATM ? resource leak?

yes, it loads the resource:// files and provides its own 'pref' function that gets triggered for every pref("blahblah",true); function call in those files

"ATM" because once they release the patch they're working on right now, those files will no longer be accessible

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

f.e. check for a single pref that's new in 55

It needs to be more precise than that, because that pref would only indicate FF55-PLUS. Like I said it wouldn't be hard to find combos of prefs+values unique to Every. Single. FF. Build. And. OS.

I would rather be in the small group (until 57 hopefully) that creates a data bit for FP of "access denied"

@L-a-n-g-o-l-i-e-r-s

This comment has been minimized.

Copy link

commented Aug 26, 2017

Was this issue resolved with today's update? 馃幈

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 27, 2017

@L-a-n-g-o-l-i-e-r-s - what issue? Do you mean resource URI - the ticket is https://bugzilla.mozilla.org/show_bug.cgi?id=863246 - unresolved as yet. If anything happens, it still takes time - it has to go thru NIghtly, then Beta, then land in stable. So 57 would be the earliest. Dot releases do not contain new features.

If you mean the addon, nah - if a legacy addon breaks it's because legacy code has been stripped - no coming back from that

@L-a-n-g-o-l-i-e-r-s

This comment has been minimized.

Copy link

commented Aug 28, 2017

@Thorin-Oakenpants
August 25, 2017
Version 55.0.3, first offered to Release channel users on August 25, 2017
Fix an issue with addons when using a path containing non-ascii characters (bug 1389160)

This didn't fix that issue? I thought the point was to mark everything legacy then tear the legs out from under it in 57. They're nothing if not inconsistent. 馃槨 鈿帮笍

Thanks 馃槄

@2glops

This comment has been minimized.

Copy link
Collaborator

commented Aug 28, 2017

@L-a-n-g-o-l-i-e-r-s
I think that fix the issue with the original addon internal code itself. The original addon should now works as well as the clone addon.
Edit : No it doesn't, the issue is with the use of relative path to load content scripts.

FF 53.0.3 don't fix the issue of accessing resource:// access to Web content.

@L-a-n-g-o-l-i-e-r-s

This comment has been minimized.

Copy link

commented Aug 28, 2017

@2glops
Right, I know the URI issue hasn't been fixed, but I was thinking that the update should have fixed the extension among the others that broke, is that true? 馃槥

I should have been more explicit with my original question, I was quite tired when I asked it, 馃槹 馃尩

Thanks

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 28, 2017

I was thinking that the update should have fixed the extension among the others that broke, is that true?

No that's not true. That bug in the update fixed an unrelated problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1389160#c47

[User impact if declined]: users with non-ascii in path (such as unicode in username) will start up with add-ons disabled

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

@earthlng

Preferences can't be accessed directly, only induced

atm all the default preferences files in FF can be accessed and read directly.

For some reason this question was in my head when I woke up: Hey sure, it can "read" what files are there, but surely it cannot "upload" them from your device and inspect the contents, right? That doesn't sound right to me. Or do you mean the local file can be integrated into content and read by JS? Can someone ELI5 how a website would read the actual pref values

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2017

Can someone ELI5 how a website would read the actual pref values

I already did ... #191 (comment)

They cannot read it in it's raw form including the js comments for example, but they can re-construct the active code parts because there are only pref() and sticky_pref() functions in those files. They could then send the reconstructed file to a server. But there's no need to do that because a handful of those pref calls are enough to detect the OS + FF version.
The browserleaks site even shows you example code that illustrates how it works.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

^^ Just as well its all locked down then. I feel a good nights sleep coming on .. no wait a minute ... damn, did you see my latest soapbox post?

@Atavic

This comment has been minimized.

Copy link

commented Aug 29, 2017

Secretary of Finance? I don't even own a credit card. :feelsgood:

@ilikenwf

This comment has been minimized.

Copy link

commented Aug 30, 2017

@earthlng https://notabug.org/desktopd/no-resource-uri-leak/pulls/16

@no-resource-uri-leak-1.2.1.xpi.zip

Despite the current FF nightly apparently fixing the resource leak issue, I doubt they have addressed extensions. Likewise I use Waterfox, anyway, which still supports XUL addons.

@fmarier

This comment has been minimized.

Copy link

commented Aug 30, 2017

From https://groups.google.com/d/msg/mozilla.dev.platform/00-1tT15mX0/TzUrOD93AAAJ:

It means there is no need to use the "No Resource URI Leak" add-on anymore.

@ilikenwf

This comment has been minimized.

Copy link

commented Aug 30, 2017

Yes, unless you use an ESR release, or Waterfox until it's merged in. That said someone here should test it first to see if it really passes the tests.

It doesn't just protect resource:// but others too...

My modded version also should prevent extension fingerprinting as well.

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

Hi @ilikenwf

thanks. You'll not gonna be able to get it signed with the same id but more importantly I think you're breaking the logic here:

-  || u.schemeIs ('about') && (!policyState.veryInsecureAboutUris.has (u.path))
-    && (policyState.secureAboutUris.has (u.path) || policyState.whitelistAboutUris);
+  || u.schemeIs ('about') || u.schemeIs ('extension') || u.schemeIs ('moz-extension') 
+	&& (!policyState.veryInsecureAboutUris.has (u.path))
+    && (policyState.secureAboutUris.has (u.path) || policyState.mozextWhitelist.has (u.path) 
+	|| policyState.extWhitelist.has (u.path) || policyState.whitelistAboutUris);

I'll have to look at it in more detail, tomorrow maybe.

@ilikenwf

This comment has been minimized.

Copy link

commented Aug 30, 2017

Waterfox doesn't force signing, so I wasn't super worried about it since I've put in a PR to the addon dev's repo...

I don't think the logic there is broken, necessarily, but it may need some parenthases for clarity because it's hard to read and was so before I even touched it...but the logic reads to me as "if the scheme is any of the things we filter and our policy of insercure about uris does not have the path, and the secure uris, or other policies has the path.....

Admittedly I did this in about 5 minutes so I'm sure it could use cleanup at the very least.

@earthlng

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

I don't think the logic there is broken

No I'm pretty sure it's broken, mate ;) It needs to be

|| u.schemeIs ('about') && all the "AboutUris" stuff

You made it

|| u.schemeIs ('moz-extension') && all the "AboutUris" stuff

You probably also only want to check for mozextWhitelist when the schemeIs ('moz-extension') etc.

it's hard to read and was so before I even touched it

I know, I nearly broke it myself when I tried to add some improvements to the addon :)

@ilikenwf

This comment has been minimized.

Copy link

commented Aug 30, 2017

@ilikenwf

This comment has been minimized.

Copy link

commented Sep 3, 2017

Yeah, still broken, that whitelist logic needs adjusted...the blocking works but the whitelists do not, meaning ublock etc options don't look or function properly.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

commented Oct 6, 2017

These two patched legacy extensions are listed on the wiki page. I doubt anything else will ever be patched by us - closing this

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