sticky: unofficial: the extension csp header modification game [1462989 + 1635781 resolved 78 / ESR78.1]

[Thorin-Oakenpants]

Anyone want a game of craps?

• required reading: uMatrix WE problem in combination with other WEs [Bug 1417249, 1477696, 1421725...] #265
• bugzillas: 1421725, 1417249 marked duplicate of 1477696, and 1462989
• short description: when two or more extensions use CSP injection to modify headers on the same page, only one wins. It doesn't matter who: first loaded, first modified - don't care: the fact is only one extension will achieve what it is meant to, the other(s) will fail
• FYI: The wiki page for extensions has been updated to reflect just how dangerous this is (such as JS blocking not getting blocked), but is by no means definitive

Use this sticky to report where settings use CSP: especially in our recommended extensions - outside of those, I don't really care, but it would be interesting, for example, to know that other popular extensions such as ABP or even Chameleon cause issues

⭐ CSP header injection is used extensively in uBlock Origin, for example (see gwarser's comment four posts down). The entries below are some features you could consider disabling (or achieving another way) to reduce CSP header injection issues, depending on what extensions you use. It is up to you to determine what mix you want

template

- extension: 
- setting:
   * comment
- solution:

TIP from gwarser 💋 CRX viewer and search for !content-security-policy. (! means scan all files.) If they touch this header, they are potentially unsafe.

[Thorin-Oakenpants]

• extension: uBlock Origin
• setting: uncheck Dashboard>Settings>Block remote fonts
  • This sets a font rule and font rules use CSP header modification [no word from gorhill if font filters are an issue, asked twice, I guess he's busy - @gwarser then]
• solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)

[Thorin-Oakenpants]

• extension: Canvas Blocker
• setting: Misc > Block data URL pages
• solution: uncheck it. Not sure if RFP covers this, but it certainly causes blockage failure as seen in multiple issues raised at CB's repo

[Thorin-Oakenpants]

• extension: HTTPS-Everywhere
• setting: uncheck toolbar icon dropdown> Encrypt All Sites Eligible (EASE)
  • by default this is unchecked
• solution: make sure any bookmarked URLs are HTTPS and disable any mixed content. Maybe use a different extension like HTTPZ - disclaimer: you will need to check any extension yourself to make sure it does not use CSP header injections

[gwarser]

This will not be so easy in uBO. I don't think CSP can be safely disabled without modifying uBO code. Also, disabling CSP filtering will cripple uBO a lot. uBO will need to be the one extension with CSP enabled.

Starting from here: https://github.com/gorhill/uBlock/blob/87feb47b51202cb8464eab91597b706965a224f3/src/js/traffic.js#L764

• Inline script filtering is powered by CSP (except for HTML filtering - ##^, but this will not work for all scripts)
  • dynamic filtering - example: example.com * inline-script block
  • static filtering - ||example.com^$inline-script (over 100 filters total)
  • "no scripting" feature - no-scripting: * true
• Inline fonts:
  • "Block remote fonts" feature - no-remote-fonts: example.com true. Related code: 1 (called for main_frame), 2, 3 (Not related to $font network filtering option)
  • $inline-font static filter option, but I cannot find even one in my dump of uBO compatible filters from filterlists.com
• Any filter list can use $csp= filters, and there are lot of them. ~400 in uBO "Filter lists", over 800 total.

[tartpvule]

• extension: uMatrix
• settings:
  • Inline script blocking
  • Inline style blocking
  • "Forbid web workers"
• solution: just be aware that these features use CSP header injection, so perhaps to reduce the possibility of conflicts, depending on your extensions and their settings, set per scope if possible?

FYI, if it is ever used by security extensions, Feature-Policy will have much of the same problems as today's CSP.

[curiosity-seeker]

* solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)

I think you mean this one. It doesn't answer the question if font filters cause this problem as well or not, though.

[gwarser]

About "font" blocking:

CSP is used only for blocking inline fonts (base64 encoded). Inline fonts are blocked only when "No remote fonts" popup switch is used, or if specified in static filter option $inline-font. $font option block by classic web request blocking.

[curiosity-seeker]

@gwarser : Just to make this perfectly clear: $font does not use CSP, and $inline-font does not use CSP, either. Correct?

[atomGit]

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

[curiosity-seeker]

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

Yes, you're right. According to this wiki site $inline-font uses CSP.

[ghost]

Hello there,

I'm sorry for the months of silence, life found its way to catch up to me and stomp me hard.
HTTPS-Everwhere's team is now aware of the CSP issue (HTTPS-E conflicts with NoScript in Tor Browser at Safest security setting when the EASE mode is enabled #17735).
I'm hoping that since this affects TBB, Firefox's developers will see how critical this issue actually is.
Much luv' and congrats on the spring cleaning! It was so easy to get back in the privacy game thanks to your efforts on the documentation and pref cleaning, I'm baffled. Overrides also are much fewer than they used to be. :D

claustromaniac's edit: The creepy stalker is back! (you didn't think I would forget about that, did ya?)
Aeriem's edit: Oh for Pants' sake, why did it have to stick? cries in stalker Still, it's heart-warming to see you haven't forgotten me despite my long absence! ❤️

[pipboy96]

This is why there should be an official way to apply CSP and FP to web pages that's standardised, instead of current hackish way.

[ghost]

I completely agree.
Hopefully this will be resolved in the near future.
Can anything be done to help?

[girst]

On Sun, May 24, 2020 at 03:09:23AM -0700, travankor wrote: [According to security expert Daniel Micay](https://old.reddit.com/r/firefox/comments/gokcis/firefox_is_insecure_refuted/frlmdwu/), firefox "fails open" when it comes to web extensions?

did some tests: yes that seems to be the case D: i do understand why firefox does it this way (not every extension is designed to block requests, and the browser would be completely unusable if it were to block all network requests when an extension dies)

Is this relevant to the discussion?

well, not directly to the topic of this thread

If UBO dies from OOM, will firefox allow arbitrary connections?

yes. there are some steps to reproduce, with today's nightly: 1. install umatrix and ublocko 2. navigate to https://gir.st/tmp/webfont.html 3. in ublock, block remote fonts. in umatrix block javascript 4. reload with ctrl-f5 and notice requests are blocked 5. in a seperate tab, go to about:memory and hit "Measure" on the right, you'll see a list of all of fx's processes. note the one called "WebExtensions" and its process id. 6. open a terminal and issue `kill $PID_OF_WEBEXTENSION_PROCESS` 7. click on Measure again. the WebExtensions process should be gone. (if it isn't, kill -9 it, maybe) 8. reload with ctrl-f5 and notice requests are now going through. the browser console / terminal i started fx from will also fill with errors. as far as i can tell, the webextension process is _not_ restarted automatically. after a few minutes, i restarted the browser to get it back. in my opinion, that last part, is the actual bug: if the webextension process dies, it should restart automatically, or at the very least warn the user. right now, the extension icons still show in the chrome, and only when clicking on them you'll notice that the extension doesn't respond. looking at BMO, this appears to already be tracked: https://bugzilla.mozilla.org/show_bug.cgi?id=1355239 -- and it even has an assignee since a few days :D

[girst]

digging around in the bugs mentioned in the one from the last email: this comment[1] mentions `extensions.webextensions.remote`. setting it to false runs webextensions from "the parent/main process"[2]. there also appears to be a `extensions.webextensions.background-delayed-startup` pref that might be interesting[3] to some of you (i haven't found much documentation, other than a note that it is not going to stick around forever). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1627139#c8 [2]: https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/modules/libpref/init/StaticPrefList.yaml#3343 [3]: https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/browser/app/profile/firefox.js#70

[girst]

apologies for the spam (last one, i promise). some caveats regarding webextensins.remote:

As Andrew noted, extensions.webextensions.remote is not really supported. Its removal was planned in bug 1613141, but I'll hold off from doing so until we have a decent recovery strategy for extension process crashes (especially since we cannot remove all related code until we support out-of-process extensions on mobile).

https://bugzilla.mozilla.org/show_bug.cgi?id=1627139#c10

[Thorin-Oakenpants]

indeed .... https://github.com/uBlockOrigin/uMatrix-issues/issues/231#issuecomment-596062505

[curiosityseeker]

yes. there are some steps to reproduce, with today's nightly: 1. install umatrix and ublocko 2. navigate to https://gir.st/tmp/webfont.html 3. in ublock, block remote fonts. in umatrix block javascript 4. reload with ctrl-f5 and notice requests are blocked 5. in a seperate tab, go to about:memory and hit "Measure" on the right, you'll see a list of all of fx's processes. note the one called "WebExtensions" and its process id. 6. open a terminal and issue kill $PID_OF_WEBEXTENSION_PROCESS 7. click on Measure again. the WebExtensions process should be gone. (if it isn't, kill -9 it, maybe) 8. reload with ctrl-f5 and notice requests are now going through. the browser console / terminal i started fx from will also fill with errors. as far as i can tell, the webextension process is not restarted automatically.

Thanks, I could reproduce. This should not happen. However, the question is: how relevant is this in practice? I've never seen my extensions dying. But obviously it does happen according to the uMatrix issue mentioned by Pants.

looking at BMO, this appears to already be tracked: https://bugzilla.mozilla.org/show_bug.cgi?id=1355239 -- and it even has an assignee since a few days :D

Good. If Rob Wu takes care of it a solution should not be far away.

[girst]

On Sun, May 24, 2020 at 07:43:09AM -0700, curiosityseeker wrote: Thanks, I could reproduce. This should not happen. However, the question is: how relevant is this in practice? I've never seen my extensions dying. But obviously it does happen according to the uMatrix issue mentioned by Pants.

I guess you have to be both a tab hoarder and only limited amount of memory available. I can't say I personally seen it happen on any of my machines. If you're worried you might be affected, I cobbled together a small shell script that can warn you whenever the process dies. tail --pid=`grep -H WebExtensions /proc/*/comm | awk -F/ '{print $3}'` -f /dev/null && zenity --info --text 'WebExtension process died!' It's a bit dense, but here's how it works: - we search all available processes' comm file for the name of the process, "WebExtensions", and extract the PID (grep -H includes the path in the output, which we split on '/' and extract the PID w/ awk) - tail --pid (another gnuism) waits for a process with said pid to exit - once tail exits, pop up a info box using zenity. this could of course be replaced by anything you'd want to do when this happens (e.g. kill firefox).

[Thorin-Oakenpants]

This OOM / extention-hard-fail is OT, but I thought I would share, because sharing is caring - anyone want a hug? I haven't broken my solitude or left my shack in the remote woods for eight weeks, and I promise to shower with lots of soap first. Any takers? I'll be gentle.

@geeknik mentioned, in a now deleted post (why do you keep deleting posts right after you make them), defense in depth, about using something like PiHole on the router. Sure. You could also use the OS level.

Now I was thinking about Tor Browser users, and how TB doesn't ship with any adblocking (except tails). And this can be detected, indeed, even specific rules. All TB users on Tails should look the same in this regard, assuming that the default lists are static, lists used are not changed, custom filters/rules aren't added, etc.

IANAE on this: Does PiHole or similar affect your Tor Browser fingerprint. I mean, you're not the one making the final request for the content, so does it still come through, or is it blocked?

Besides that: when/if TB ships with some sort of adblocker (needs a lot of work, investigating: but gk is totally against blocking ads since it enables content: i.e it would also hurt the little guys): imagine the savings on the Tor network :)

[curiosityseeker]

I guess you have to be both a tab hoarder and only limited amount of memory available.

Indeed, I don't belong to that group.

tail --pid=grep -H WebExtensions /proc/*/comm | awk -F/ '{print $3}' -f /dev/null && zenity --info --text 'WebExtension process died!'

Cool ! I don't think that I need it - but I've learned something new from it. Thanks!

[curiosityseeker]

Does PiHole or similar affect your Tor Browser fingerprint. I mean, you're not the one making the final request for the content, so does it still come through, or is it blocked?

It is blocked. FWIW, I'm not using PiHole but dnscrypt-proxy with a huge blocklist. I've just tested it on https://browserleaks.com/proxy with uBO disabled. It didn't detect any content filters or filter subscriptions (which it does if uBO is enabled). Hence, the TB fingerprint should not be affected. Although that's certainly not a guarantee: If something is blocked by that blocklist which is also blocked by one of the well-known filterlists, it might be misinterpreted by the code running on such sites.

However, needless to say that solutions like PiHole, dnscrypt-proxy or AdGuardHome block adservers and tracking/malware domains on the DNS level very efficiently. But they are not able to block something like, e.g.,

https://a.nytimes.com/svc/nyt/data-layer?sourceApp=nyt-vi&referrer=&assetUrl=https%3A%2F%2Fwww.nytimes.com%2F&

which is blocked in uBO by the following rule: ||nytimes.com^*/data-layer? So both blocking approaches are not really comparable.

[travankor]

I'm on FF 77.0.1 and the parent issue is still there. I'm using an old profile and disabled and re-enabled all extensions. I will try this on a new profile later on.

[girst]

On Fri, Jun 05, 2020 at 05:54:42AM -0700, travankor wrote: I'm on FF 77.0.1 and the parent issue is still there. I'm using an old

How did you determine if it's still broken? If you can give me your STR and list of extensions I'll have a look.

[travankor]

I tried the test you added here on a clean profile (no user.js) and it fails everything.

In the console, I have TypeError: setting getter-only property "suspended".

I think this might be unrelated to the bug in this thread.

[girst]

On Fri, Jun 05, 2020 at 08:12:58AM -0700, travankor wrote: I tried the test you added [here](...) on a clean profile (no user.js) and it fails everything.

I just re-did the test. After you deactivate and reactivate the addons, you'll need to re-disable webfonts/javascript. It looks like, if you don't save those changes, they get reset when you disable the addon (which makes sense, in hindsight).

In the console, I have `TypeError: setting getter-only property "suspended"`. I think this might be unrelated to the bug in this thread.

can't reproduce this.

[travankor]

This took an embarrasingly long time to figure out (although I realized as soon as I took a break and came back to this), but I had an obsolete autoconfig.js file in my firefox root directory.

I was under the impression that my package manager would have cleaned up these obsolete files a while ago, but apparently this is not the case... moral of the story: trust but verify.

[travankor]

you'll need to re-disable webfonts/javascript. It looks like, if you
don't save those changes, they get reset when you disable the addon

Note that user.js has a option that disables webfonts, too (or, at least, your test fails with this option set). However, it seems like UBo blocks more content than the native FF option.

And HTTPS Everywhere needs to be refreshed twice for it to take effect although you can use HTTPZ as an alternative

[gwarser]

https://bugzilla.mozilla.org/show_bug.cgi?id=1635781 "Cannot replace frame-ancestors directive of the Content-Security-Policy HTTP Header via the webRequest API" was fixed.

---

This commit fixes the bug by tracking the CSP status on the
ResponseHeaderChanger instance, which is shared by all webRequest
handlers of a single request.

So it was possible after all to track this between processes?

[travankor]

cc @girst

[girst]

On Thu, Jun 25, 2020 at 02:18:39AM -0700, travankor wrote: cc @girst

no need to ping me, i'm still cc'd to this bug ;-) it looks like this breaks the fix, according to a quick test i did. i already commented on the ticket on bmo with a shortened version of the str i provided to this thread earlier. https://bugzilla.mozilla.org/show_bug.cgi?id=1635781#c18

[girst]

well, embarrassing: repeating the test made it work again. :| (and there /is/ a regression test for it...which i wrote. and it evidently passed that one on check-in)

[Thorin-Oakenpants]

So this is "fully" resolved now in 78+ and ESR78.1 (when it comes out)

[jawz101]

Does this mean this wiki page is no longer relevant? I'd rather not have to think about all of the factors it suggests to toggle in each extension or whether NoScript is not a recommended addon if the issue is now a non-issue.

[Thorin-Oakenpants]

if you're on stable, then the CSP stuff doesn't apply to you. Once ESR68 reached end-of-life, I will remove all the CSP warning