search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.92k stars 512 forks source link

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

Closed Thorin-Oakenpants closed 4 years ago

Thorin-Oakenpants commented 5 years ago

Anyone want a game of craps?

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

:star: 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 :kiss: CRX viewer and search for !content-security-policy. (! means scan all files.) If they touch this header, they are potentially unsafe.

Thorin-Oakenpants commented 5 years ago
Thorin-Oakenpants commented 5 years ago
Thorin-Oakenpants commented 5 years ago
gwarser commented 5 years ago

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

tartpvule commented 5 years ago

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

curiosity-seeker commented 5 years ago 
* 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 commented 5 years ago

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 commented 5 years ago

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

atomGit commented 5 years ago

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 commented 5 years ago

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.

atomGit commented 5 years ago

WTF went wrong with github's clock

nothing, why? we posted those comments about 7 hrs. ago, honest - you know, they say people who've been abducted by aliens experience missing time

claustromaniac commented 5 years ago

dafuq

ghost commented 5 years ago

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! :heart:

pipboy96 commented 5 years ago

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 commented 5 years ago

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

ghost commented 5 years ago

Imma scared, did you infiltrate Mozilla's headquarters? 😱 Blink twice if you need us to exfiltrate you quickly!

I'm curious though, are you working with the devs from the Bugzilla tickets you linked? Because that'd be super cool.

pipboy96 commented 5 years ago

@Thorin-Oakenpants Um, everything's fine? Should we be scared?

ghost commented 5 years ago

Must admit I had to reread some sentences to fully get you haha! But I'm no better with mine, so who am I to judge? 🤷

I feel like the conversation is getting a bit personal and out of the scope of this git issue, but I'd love to carry it on somewhere else (if you don't mind). Hit me up if you want to. Still, I'm sorry for your loss and your work is appreciated. I learned so much from this repo.

@pipboy96 Thank you again for taking the time to review this issue, and sorry for the flood. Also, Pants quirky personality is one of the reasons this repo is quite fun to read.

crssi commented 5 years ago

Yeah, maybe @Thorin-Oakenpants is not aware of, but a most of times the writing is real fun to read. Sorry for the loss.

pipboy96 commented 5 years ago

@Thorin-Oakenpants I'm sorry for your loss. May your friend rest in peace.

atomGit commented 5 years ago

sorry about your loss Pants - wish i had some magic words that would help, but i never know what to say in circumstances like this

Can anything be done to help?

vote for 1421725

atomGit commented 5 years ago

what happens if content_security_policy is contained in the manifest of an add-on, but content-security-policy isn't contained anywhere?

"content_security_policy": "default-src 'self'; connect-src ws:; style-src 'self' 'unsafe-inline'"

gwarser commented 5 years ago

This key in manifest applies only to extension https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy

Your example is bit unusual with (not encrypted) websocket and inline stylesheets.

atomGit commented 5 years ago

ok, i understand now - Echo for Kodi is the ext. i'm referring to btw

WellOrientedLlama commented 5 years ago

Just for the record, it seems that the last add-on to be loaded by Firefox wins the race and gets its HTTP header changes through, crushing other extensions' tweaks.

So my Firefox starts with the page about:addons, and on each startup and each add-on update, I disable uMatrix and reenable it again, so it is always the last add-on to be loaded by the Fox. Then it wins against uBlock Origin's relevant features which is what I wanted.

This bug really cries for people not to install many add-ons, it sucks. And Kris Maglione's stance bah, it's okay, let's say there's nothing to do also sucks.

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ? uBO's blob: or data: filters are also affected, if I recall correctly (been a while), though I don't know how uBO translates them internally.

Atavic commented 5 years ago

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ?

Any addon race that's conflicting on the same header's modification acts the same.

earthlng commented 5 years ago

Additionally I...don't think it's limited to CSP

no it's not limited to CSP but CSP is the most important one if you care about reliably blocking inline Javascript.

Shouldn't any HTTP header be affected

yes any HTTP header is affected if 2 or more addons try to modify the same header

uBO's blob: or data: filters are also affected

yes but AFAIK uBO blocks or limits those by using a CSP header

kah0922 commented 4 years ago

Well, it seems like shit is actually being worked on now in bug 1262989.

travankor commented 4 years ago

Alternatively, recompile Firefox with the patch from this repo https://github.com/tartpvule/my-firefox-patches (see #265, except it's closed)

I'm disappointed that neither Tor nor mozilla care about this issue -- maybe it's an intentional loophole to make it easier to identify Tor browser users?

andretiagogr commented 4 years ago

I'm disappointed that neither Tor nor mozilla care about this issue -- maybe it's an intentional loophole to make it easier to identify Tor browser users?

Tor doesn't recommend installing extensions and NoScript and HTTPS Everywhere won't conflict with each other because EASE is disabled by default. That's probably why Tor doesn't care

KOLANICH commented 4 years ago

EASE is disabled by default

That's shit.

rusty-snake commented 4 years ago

EASE is disabled by default

That's shit.

Default security level: Standart Reason: compatibility

atomGit commented 4 years ago

just a heads up on the CSP issue :)

Status: NEW → ASSIGNED

Thorin-Oakenpants commented 4 years ago

I know. I've kept a close eye on it since day 1. I've actually met Shane (mixedpuppy). Anyway, I created a new label to apply to #265 and this ticket when it gets done

jesus

It's also going to get used on #448 because a solution for that is actually already available, it just needs some perf work before it lands gets flipped on (not going to say anymore since the tickets are access denied)

atomGit commented 4 years ago

support merging content-security-policy headers provided by multiple extensions Status: RESOLVED FIXED Milestone: mozilla77

anybody know what "fixed" means? i looked at the latest activity and i have no idea how this was fixed or what the fix translates to in terms of how extensions are affected

gwarser commented 4 years ago

Previously, when original response had CSP header and extensions tried to set another, extension api had knowledge of original (from server) header and was able to set headersAlreadySet flag which instruct Firefox to merge headers.

When original response did not had CSP header, extensions running in different threads "at once" did not have chance to read headersAlreadySet set by other extension, so all extensions thought that they have only header and they do not instruct Firefox to merge headers - only one "win".

Now headersAlreadySet for CSP is pre-set / hardcoded, so extensions headers will always be merged.

atomGit commented 4 years ago

thank you for that explanation, but it's a bit over my head technically

currently i have 3 extensions that make use of CSP, one being uMatrix

in order to ensure that uM takes precedence, every time i start FF i must disable, then enable uM so that it becomes the last (or first?) in the chain, else in-line JS may not be blocked

so my question is, would one still need to do this in FF 77?

given your explanation, i'm guessing the answer is 'no', but i'm not sure

Thorin-Oakenpants commented 4 years ago

I'll await anointing any jesus was listening labels until it's all been tested. My understanding is that there are still potential issues e.g. if two headers clash- but IANAE

uBlock-user commented 4 years ago

That bug specifically fixes CSP header clashes with a force merge, nothing else. All other headers may still clash.

travankor commented 4 years ago

Is there a tl;dr of what we need for a comprehensive fix (ie: what's left to do)?

Thorin-Oakenpants commented 4 years ago

Is there a tl;dr of what we need for a comprehensive fix (ie: what's left to do)?

curiosityseeker commented 4 years ago

That bug specifically fixes CSP header clashes with a force merge, nothing else. All other headers may still clash.

Okay - but since the problem we're discussing here is about CSP headers (and not about other headers) it should be fixed now, shouldn't it?

uBlock-user commented 4 years ago

Fixed in Nightly yes.

girst commented 4 years ago

Hi, I'm the guy who wrote the patch. Oof, what a journey! If you want a pracical easy-to-repeat test, try this:

  1. install uBlock Origin (optional, for 2nd and 3rd tests)
  2. install uMatrix
  3. install HTTPS Everywhere (order matters!) alternatively, disable and reenable the extensions in the above order to make sure their CSPs have the expected precedence
  4. navigate to http://girst.2ix.at/tmp/webfont.html observe:
    • it will not redirect to https://...
    • "Javascript is enabled"
    • "Webfonts are [][][][][][][][]" (enabled)
  5. block javascript using umatrix and refresh page observe:
    • "Javascript is disabled"
  6. enable "encrypt all sites" in https everywhere and refresh page observe in nightly:
    • you are redirected to https://...
    • "Javascript is disabled" observe in release:
    • you are redirected to https://...
    • "Javascript is enabled" (!!!)

optional 2nd test:

  1. enable font-blocking in uBlockO
  2. using ctrl-f5, clear the cache and refresh the page observe in nightly:
    • "Webfonts are disabled" observe in release:
    • "Webfonts are [][][][][][][][]" (enabled) (!!!)

optional 3rd test:

  1. disable and reenable uMatrix
  2. disable and reenable uBlockO
  3. reload page observe in nightly:
    • everything still works observe in release:
    • "Javascript is enabled" (!!!)
    • "Webfonts are disabled"
    • unexpectedly, upgrade-insecure-requests still works (maybe some browser caching going on?)
uBlock-user commented 4 years ago

@girst Thanks, without you, this bug would have never been fixed. Does this issue still exist for lets say Feature-Policy or any other header ?

girst commented 4 years ago

On Thu, Apr 16, 2020 at 07:09:11AM -0700, Saitama wrote:

Does this issue still exist for lets say Feature-Policy or any other header ?

yes. i submitted 2 variations of the patch, one that would apply to all headers, and one that only applies to c-s-p. mozilla/mixedpuppy went with the second one.

however, adding Feature-Policy to the exception "must-merge" list would be pretty easy: just add it to the headersAlreadySet set (and add a test, of course).

travankor commented 4 years ago

According to security expert Daniel Micay, firefox "fails open" when it comes to web extensions.

@uBlock-user @girst

Is this relevant to the discussion? If UBO dies from OOM or a malicious adversary, will firefox allow arbitrary connections?

girst commented 4 years ago

On Sun, May 24, 2020 at 03:09:23AM -0700, travankor wrote:

According to security expert Daniel Micay, 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 commented 4 years ago

digging around in the bugs mentioned in the one from the last email: this comment1 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 interesting3 to some of you (i haven't found much documentation, other than a note that it is not going to stick around forever).

girst commented 4 years ago

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