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

[earthlng]

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

• NoRedirect (clone) - original AMO here
  • author: earthling
  • fixes the missing multiprocessCompatible flag
• No Resource URI Leak (clone) - original AMO here
  • author: earthling
  • The original add-on broke in FF55+

---

@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

[AdKiller]

Thanks for fixing No Resource URI Leak (clone).

[earthlng]

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

[ghost]

@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]

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

[earthlng]

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]

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]

@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]

[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]

:)

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

[earthlng]

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]

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]

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]

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]

Was this issue resolved with today's update? 🎱

[Thorin-Oakenpants]

@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]

@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]

@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]

@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]

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]

@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]

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]

^^ 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]

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

[ilikenwf]

@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]

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]

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]

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]

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]

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]

Pushed that tweak.

…

On Wed, Aug 30, 2017 at 4:00 PM, earthlng ***@***.***> wrote: I don't think the logic there is broken No I'm pretty sure it's broken. It needs to be *||* u.schemeIs ('about') *&&* all the rest of it. You made it *||* u.schemeIs ('moz-extension') *&&* all the rest of it. 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 ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZUOqGTu0K8DKRybL22sg3S4K_yEXmBks5sdc1bgaJpZM4OwAW1> .

[ilikenwf]

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.