MarioNet Browser Attack

[heinoganda]

5 minutes ago, Sampei.Nihira said:

I will never,never,never,install Chrome/Chromium

You can stay with whatever browser you want, but do not compare apples to oranges. In the meantime, a lot has happened with the Chromium version, so with version 72 that works too, but not with the older versions, regardless of the current version of μMatrix or μBlock (experiment with version 1.17.4).

[Mathwiz]

That's interesting @Sampei.Nihira; I was never able to get a version later than 1.17.4 to run on Serpent 52, which is forked from (IIRC) FF 52.6. I never bothered trying on later FF versions; I just figured they'd stop at 1.17.4 too.... (uBO 1.18.4 runs on Serpent 55, but that was forked from an alpha version of FF 53....)

So it seems Mozilla did more than mere "security fixes" between 52.6 and 52.9.1.

[VistaLover]

5 minutes ago, Mathwiz said:

I figured it out on my own eventually and edited my above post accordingly.

...Good to know ; when I started composing my post (which involved test installation attempts, taking a screenshot and uploading to the image hoster...), your "Edit" just wasn't there; and before I clicked "Submit Reply" in my finished post, I did not bother checking the status of your previous post...

[Mathwiz]

I guess our posts crossed in the Ethernet

Sorry to have derailed the thread; of course uBO isn't even needed to block Service Workers in FF et al. Even if you use a version (FF 51) where they're enabled by default, you can just toggle support off in about:config and be done with it.

[Sampei.Nihira]

20 minutes ago, heinoganda said:

You can stay with whatever browser you want, but do not compare apples to oranges. In the meantime, a lot has happened with the Chromium version, so with version 72 that works too, but not with the older versions, regardless of the current version of μMatrix or μBlock (experiment with version 1.17.4).

What version of uMatrix did you install to make that failed test?

The switch: "Forbid web workers" is available from version 1.2.0.

Edited March 6, 2019 by Sampei.Nihira

[Mathwiz]

3 hours ago, Mathwiz said:

That's interesting @Sampei.Nihira; I was never able to get a version later than 1.17.4 to run on Serpent 52, which is forked from (IIRC) FF 52.6. I never bothered trying on later FF versions; I just figured they'd stop at 1.17.4 too.... (uBO 1.18.4 runs on Serpent 55, but that was forked from an alpha version of FF 53....)

So it seems Mozilla did more than mere "security fixes" between 52.6 and 52.9.1.

Turns out, it wasn't so much Mozilla as @Sampei.Nihira. I tried my own copy of FF 52.9.1 and, sure enough, I was stuck at 1.17.4.

Once again, @VistaLover to the rescue:

On 1/21/2019 at 7:28 PM, VistaLover said:

A word to those using uB0 WE on Basilisk/Serpent 52.9.0 :

1.17.4 is the final version that can be installed in Basilisk 52 out of the box; 1.17.7b2 of the dev channel was (has now been removed from the GitHub repo) equally the last (beta) version to install (out-of-the-box) in either Basilisk 52 / Serpent 52.9.0; this development has been reported first in the official PM forums, 

https://forum.palemoon.org/viewtopic.php?f=61&t=21241

which also links to the uB0 support reddit:

Mozilla fanbois aside (they're so irritating , aren't they?), it was claimed that "Basilisk was never officially supported", while in the end of the thread the author revealed that he had to increase "strict_min_version" (inside extension's manifest.json) to "55.0", because he started using the Web API requestIdleCallback. So, latest dev version 1.17.7rc2 won't install in Bk52

I've done some research and have discovered at least two discrepancies here:

1. For some inexplicable reason, Firefox versions 52.0.2 and 53.0.3 (release channel) as well as 52.9.0 (ESR channel) do not honour the "strict_min_version": "55.0" requirement and version uB0 1.17.7rc2 has no problem installing and working there...

2. While the MDN documentation states that window.requestIdleCallback() is "Implemented but disabled by default" in Firefox v53-55, I found boolean pref "dom.requestIdleCallback.enabled" extant (but defaulted to false) in all 3 mentioned Firefox versions (52.0.2, 52.9.0, 53.0.3); so, at least in theory, Firefox >=52.0 already meets the new requirement by @gorhill, provided the user manually flips "dom.requestIdleCallback.enabled" to true.... - but, sadly, @gorhill does not follow closely Basilisk's development, hence his decision to block it based solely on its reported appVersion string ; also worth noting is that Serpent 55.0.0/moebius doesn't exhibit this issue because, its appVersion string reporting 55.*, it already fulfills the new enhanced requirements...

To cut a long story short, I downloaded file uBlock0_1.17.7rc2.firefox.signed.xpi to disk and manually changed line 5 in manifest.json file to read:

     "strict_min_version": "52.0",

... then the extension had no problem installing and working as expected in Serpent 52.9.0 

All of the above applies to FF 52.9.1 also, so one must:

1. Toggle dom.requestIdle.Callback.enabled in about:config to "true"
2. Set a general.useragent.override string to at least rv:55.0; otherwise addons.mozilla.org won't even let you download the latest version
3. Once downloaded; FF 52.9.1 (unlike FF 52.0.2/0.3/9.0) will disable it due to the "strict_min_version" string mentioned above; unfortunately, changing extensions.lastAppVersion in about:config from 52.9.1 to 55.0.0 doesn't help; so to get around this, one must manually edit manifest.json in <profile folder>\Extensions\uBlock0@raymondhill.net.xpi as above

However, unlike Basilisk/Serpent, FF also requires add-ons to be signed; doing #3 invalidates the signature, and FF 52.9.1 still won't run it! (That's not quite as ridiculous as Chrome, but it's starting to get pretty close.)

There must be a way around that, as seen from @Sampei.Nihira's post showing uBO 1.18.4 running on FF 52.9.1; but no one seems to be talking. I'm starting to feel like I'm chasing the proverbial undomesticated fowl....

(Side note: as I've posted elsewhere, on FF/Serpent I actually prefer to run the legacy version of uBO, since it lets me stop WebRTC's IP address leak; and I don't use FF for day-to-day browsing anyway. So this is purely an intellectual exercise. Still, how ... ?)

Edited March 6, 2019 by Mathwiz
changing extensions.lastApp.Version fails

[heinoganda]

2 hours ago, Sampei.Nihira said:

What version of uMatrix did you install to make that failed test?

The switch: "Forbid web workers" is available from version 1.2.0. 

They just do not want to understand that it does not work in the older Chromium versions! So as not to make you sleep, μMatrix version 1.3.16. If it's so hard to install a VM and install a Windows XP, then you can convince yourself that in the older Chromium versions the trick with μBlock and μMatrix does not work, I would have preferred it. The proxy solution is of course inconvenient for the normal user, but there is no choice. For Firefox, it is a simple service worker to disable. Otherwise, the topic is done for me.

[VistaLover]

8 hours ago, Mathwiz said:

• Set a general.useragent.override string to at least rv:55.0; otherwise addons.mozilla.org won't even let you download the latest version

Not needed at all if you download the extension [file uBlock0_1.18.4.firefox.xpi] (to disk) from the GitHub repository:

https://github.com/gorhill/uBlock/releases/tag/1.18.4

8 hours ago, Mathwiz said:

However, unlike Basilisk/Serpent, FF also requires add-ons to be signed; doing #3 invalidates the signature, and FF 52.9.1 still won't run it!

Only Release/Beta Firefox branches observe extension signing (without an easy way to override it; one exists for Fx <=56, but it's OT here); Firefox ESR 52.9.0 (and the tinderbox build Firefox ESR 52.9.1), belonging to the ESR update channel, provides an easy way to disable extension signing via a user-configurable "about:config" pref:

https://wiki.mozilla.org/Add-ons/Extension_Signing

Quote

What about private add-ons used in enterprise environments?

The ESR release supports signing starting with version 45-based releases. Signing enforcement is enabled by default in these releases, and enforcement can be disabled using the xpinstall.signatures.required preference.

8 hours ago, Mathwiz said:

There must be a way around that, as seen from @Sampei.Nihira's post showing uBO 1.18.4 running on FF 52.9.1; but no one seems to be talking. I'm starting to feel like I'm chasing the proverbial undomesticated fowl.... 

Nothing occult or clandestine here

1. Download file "uBlock0_1.18.4.firefox.xpi" to disk from GitHub

2. Using 7-zip, change "strict_min_version" to "52.0"

3. Disable extension signing in FxESR 52.9.1

4. Install modified extension file via drag-n-drop in "about:addons"

There...

Edited March 7, 2019 by VistaLover

[Mathwiz]

Well, the critical piece I needed was how to disable signing enforcement.

16 hours ago, VistaLover said:

Not needed at all if you download the extension [file uBlock0_1.18.4.firefox.xpi] (to disk) from the GitHub repository

... which is the first thing I tried, but of course, that one isn't signed. So, I went to AMO, thus requiring the user-agent override to download the signed version....

... then I ran into the minimum version issue, which I fixed as you described; after which the signature was of course no longer valid, but I thought maybe FF only checked that on download. No such luck; it rechecks add-on signatures on every browser restart, I guess in case malware tries to hijack a common add-on (like uBO).

So, I ended up with a different procedure, but the end result is the same:

On 3/6/2019 at 1:12 PM, Mathwiz said:

• Toggle dom.requestIdle.Callback.enabled in about:config to "true"
• Set a general.useragent.override string to at least rv:55.0 (otherwise addons.mozilla.org won't even let you download the latest version); once downloaded; FF 52.9.1 (unlike FF 52.0.2/0.3/9.0) will disable it due to the "strict_min_version" string mentioned above; unfortunately, changing extensions.lastAppVersion in about:config from 52.9.1 to 55.0.0 doesn't help; so to get around this, one must:
• Toggle xpinstall.signatures.required in about:config to "false"
• Close the browser (otherwise the .xpi file is in use and you can't perform the next step)
• manually edit manifest.json in <profile folder>\Extensions\uBlock0@raymondhill.net.xpi as above 
• Restart the browser

All except step 2 are required in any case; step 2 is only needed to download a signed version from AMO vs. an unsigned version from Github, which may provide a bit more peace of mind for the paranoid (at least you'll know it had a valid signature when you downloaded it).

(BTW, even though signatures are no longer enforced, they are still checked, so once the .xpi is modified a warning will appear on the about:addons page, as can be seen in @Sampei.Nihira's screen shot. But since we know why the signature is invalid, we can just ignore the warning.)

Also, of course, when uBO 1.18.5 appears (being worked on now), FF will auto-update to it only if the user agent has been overridden, after which you must redo the last three steps above. If the user agent has not been overridden, you'll remain at 1.18.4 until you manually download the (unsigned) update from Github and redo the last three steps.

At the end of the day, I guess the point I was passively-aggressively trying to make is: with FF or Serpent, you're stuck at uBO 1.17.4 unless you know how to jump through several non-obvious hoops (FF requiring more hoop-jumping than Serpent).

Edited March 7, 2019 by Mathwiz

[Mathwiz]

On 3/3/2019 at 5:44 AM, Sampei.Nihira said:

Pale Moon and Basilisk by default do not support Service Workers.

Nor do New Moon and Serpent - except Moebius (Serpent 55). Need to toggle the dom.serviceWorkers.enabled pref to false, or use the uBO rule, in that version.

[Sampei.Nihira]

3 hours ago, Mathwiz said:

Nor do New Moon and Serpent - except Moebius (Serpent 55). Need to toggle the dom.serviceWorkers.enabled pref to false, or use the uBO rule, in that version.

[Mathwiz]

On 3/5/2019 at 9:59 AM, Sampei.Nihira said:

you can enter exceptions for any problematic websites in an easier way.

With uBlock Origin, here is the general form of the exception:

*$csp=worker-src 'none',domain=~example.com

And to give a practical example, here's the rule I just started using instead of disabling service workers in about:config....

*$csp=worker-src 'none',domain=~mediafire.com|~html5test.com

... so Web workers (including service workers) are disabled except at mediafire.com (requires service workers to upload files ) and html5test.com (mostly to prove that setting the domain as an exception works; also gets 10 extra bragging points on your browser's score). But html5workertest.com still shows all x's, proving workers are blocked on domains not listed.