Opened 4 weeks ago

Closed 8 days ago

#30624 closed defect (fixed)

Disable NoScript's XSS protection to avoid the whole computer freezing

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201906, GeorgKoppen201906, noscript
Cc: ma1, acat Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We've had it numerous times now (see e.g. #25315, #24125, #22362) that Tor Browser freezes the whole computer due to NoScript's XSS protection. This is currently visible on https://zeit.de again cause by an embedded https://facebook.com/tr.

I'd finally like to stop playing this whack-a-mole game and come to a better solution. Meanwhile, we can stop enabling XSS protection given that those experiences seriously risk users abandoning Tor Browser, claiming it is broken, and moving on to a much worse solution for their privacy requirements.

Child Tickets

Change History (19)

comment:1 Changed 4 weeks ago by ma1

I doubt it's the same defect, or even similar, as the implementation of the filter has radically changed with WebExtensions, and now it runs asynchronously in its own process and shouldn't be able to block the browser, let alone the whole computer.
Could you please provide me steps to reproduce reliably?
Is it Tor Browser specific or does it affect Firefox too.
Might it be related to the pseudo-modal warning dialog (which must go away anyway anyway, with the UI redesign), rather than the filter itself?
Thanks.

comment:2 Changed 4 weeks ago by ma1

NVM, I managed to reproduce. It freezes the browser for a few seconds on 8.5 (where browser.webextensions.remote is false) while the firefox.real process gets 100% CPU.
What's more annoying, it appears to affect more than just the browser on my Ubuntu box if I turn extensions.webextensions.remote to true, which is counterintuitive (the extension should be doing its thing in its own process while the facebook HTTP subrequest is suspended) but might be due to some kind of IPC bug: this time nothing really freezes, but again for a few seconds other application become sluggish as well while a WebExtensions process takes 100% CPU.
Do Tor Browser 9.0 have extensions.webextensions.remote set to false or true?
Either way, since it's already executed asyncronously, I wanna try breaking the main InjectionChecker loop into time-capped chunks (e.g. 100ms max) which would relinquish the CPU back periodically while checking very costly payloads like this, and possibly (but it might not be necessary) move the whole in a dedicated worker.

Last edited 4 weeks ago by ma1 (previous) (diff)

comment:3 Changed 4 weeks ago by cypherpunks

ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote

Also see #29043.

comment:4 in reply to:  3 ; Changed 4 weeks ago by ma1

Replying to cypherpunks:

ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote

No, the info was not there. However I've installed 9.0a1, and extensions.webextensions.remote is still false like in 8.5.
The proposed fix should work either way, though.

comment:5 in reply to:  4 ; Changed 4 weeks ago by cypherpunks

Replying to ma1:

Replying to cypherpunks:

ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote

No, the info was not there.

Oh, you mean the absence of other tickets is not the obvious proof for you. Then only https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-browser-60.7.0esr-9.0-1#n78

However I've installed 9.0a1,

o_0 Hey folks! Maone installed TB!

and extensions.webextensions.remote is still false like in 8.5.

Trust no one.

The proposed fix should work either way, though.

Did you test that in TB?

comment:6 in reply to:  5 Changed 4 weeks ago by ma1

Replying to cypherpunks:

The proposed fix should work either way, though.

Did you test that in TB?

No I couldn't, I'm sorry: I was paralyzed in awe of the grace and the usefulness of your comments.
Not nearly as useful, and maybe exceedingly mundane, but would you by chance have also any patch (or idea for a fix) to contribute?
Thanks.

comment:7 Changed 4 weeks ago by ma1

Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc3

This should prevent any freeze, even on the heaviest payload.
Tested on 8.5 and 9.0a1.

comment:8 in reply to:  7 ; Changed 4 weeks ago by gk

Replying to ma1:

Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc3

This should prevent any freeze, even on the heaviest payload.
Tested on 8.5 and 9.0a1.

Not for me. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.

comment:9 in reply to:  5 Changed 4 weeks ago by gk

Replying to cypherpunks:

Replying to ma1:

Replying to cypherpunks:

ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote

No, the info was not there.

Oh, you mean the absence of other tickets is not the obvious proof for you. Then only https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-browser-60.7.0esr-9.0-1#n78

However I've installed 9.0a1,

o_0 Hey folks! Maone installed TB!

and extensions.webextensions.remote is still false like in 8.5.

Trust no one.

The proposed fix should work either way, though.

Did you test that in TB?

Please keep the tone civilized. It's quite embarrassing to see someone being so rude. That's not welcome here.

Last edited 4 weeks ago by gk (previous) (diff)

comment:10 in reply to:  8 ; Changed 4 weeks ago by ma1

Replying to gk:

. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.

Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too, causing the CPU to be relinquished every 100ms (which is the artificially imposed resolution), rather than 10ms as intended, therefore making long-running checks 10 times more sluggish than they should :(

Trying something else, stay tuned...

comment:11 in reply to:  10 ; Changed 4 weeks ago by ma1

Replying to ma1:

Replying to gk:

. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1).

Trying something else, stay tuned...

Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc4
Thanks!

comment:12 in reply to:  10 Changed 4 weeks ago by gk

Replying to ma1:

Replying to gk:

. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.

Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too,

That's a bug I think. I opened #30655 for that.

comment:13 in reply to:  11 Changed 4 weeks ago by gk

Replying to ma1:

Replying to ma1:

Replying to gk:

. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1).

Trying something else, stay tuned...

Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc4

That seems to work for me, thanks!

comment:14 Changed 2 weeks ago by gk

Cc: acat added

#30754 is a duplicate.

comment:15 in reply to:  10 Changed 2 weeks ago by cypherpunks

Replying to ma1:

Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too, causing the CPU to be relinquished every 100ms (which is the artificially imposed resolution), rather than 10ms as intended, therefore making long-running checks 10 times more sluggish than they should :(

@gk: You should probably raise this with Mozilla, WebExt have now their own process in moz-central so it should theoretically be easy to let resistFingerprinting conquer almost everything except the WebExt process.

comment:16 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201906 added; TorBrowserTeam201905 removed

Moving tickets to June

comment:17 Changed 13 days ago by gk

Keywords: GeorgKoppen201906 added; GeorgKoppen201905 removed

Moving my tickets to June

comment:18 Changed 8 days ago by gk

Keywords: noscript added

comment:19 Changed 8 days ago by gk

Resolution: fixed
Status: newclosed

Thanks, fixed in tor-browser-build with commit 07961f94a1d956c33c1d0448b6e5f69df6b03ea4 (on master) and 26a5d9739b7e0d30f03da46b316ac15546e79eef (on maint-8.5).

Note: See TracTickets for help on using tickets.