-
Notifications
You must be signed in to change notification settings - Fork 523
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sticky: unofficial: the extension csp header modification game [1462989 + 1635781 resolved 78 / ESR78.1] #664
Comments
|
|
|
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
|
FYI, if it is ever used by security extensions, Feature-Policy will have much of the same problems as today's CSP. |
I think you mean this one. It doesn't answer the question if font filters cause this problem as well or not, though. |
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 |
@gwarser : Just to make this perfectly clear: |
not correct - gwarser is saying that |
Yes, you're right. According to this wiki site |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hello there, I'm sorry for the months of silence, life found its way to catch up to me and stomp me hard. claustromaniac's edit: The creepy stalker is back! (you didn't think I would forget about that, did ya?) |
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. |
I completely agree. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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
|
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
|
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).
|
indeed .... |
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.
Good. If Rob Wu takes care of it a solution should not be far away. |
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).
|
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 :) |
Indeed, I don't belong to that group.
Cool ! I don't think that I need it - but I've learned something new from it. Thanks! |
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.,
which is blocked in uBO by the following rule: |
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. |
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.
|
I tried the test you added here on a clean profile (no user.js) and it fails everything. In the console, I have I think this might be unrelated to the bug in this thread. |
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.
|
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 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. |
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 |
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.
So it was possible after all to track this between processes? |
cc @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
|
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)
|
So this is "fully" resolved now in 78+ and ESR78.1 (when it comes out) |
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. |
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 |
Anyone want a game of craps?
1417249marked duplicate of 1477696, and 1462989Use 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
TIP
from gwarser 💋 CRX viewer and search for!content-security-policy
. (!
means scan all files.) If they touch this header, they are potentially unsafe.The text was updated successfully, but these errors were encountered: