Opened 4 months ago

Closed 4 months ago

Last modified 3 months ago

#28873 closed defect (fixed)

Cascading of permissions does not seem to work properly in Tor Browser 8

Reported by: gk Owned by: ma1
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: noscript, tbb-security, tbb-torbutton, tbb-8.0-issues, tbb-regression, TorBrowserTeam201812R
Cc: ma1 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by gk)

On level "safer" of our security slider we want to prevent executing JavaScript if the URL bar domain is loaded over HTTP. That means even if embedded content is loaded over HTTPS it's not allowed to load and execute JavaScript that way. We used the cascadePermissions and the globalHttpsWhitelist prefs for that in the XPCOM NoScript.

This mechanism seems to be broken as e.g. HTTPS JavaScript can get loaded in a HTTP site context (as an example take http://www.worldstarhiphop.com/featured/131305).

This got noted on our blog: https://blog.torproject.org/comment/278987#comment-278987.

Child Tickets

Change History (13)

comment:1 Changed 4 months ago by gk

Status: newneeds_information

ma1: I have not looked closer yet, but is this a NoScript issue or do we need to pass some particular flag to Noscript when we want that behavior in the WebExtensions world as well? We were under the impression we'd get this feature by only having frame, font, object and , other as UNTRUSTED caps on that slider level.

comment:2 Changed 4 months ago by gk

Resolution: worksforme
Status: needs_informationclosed

Huh, I could have sworn that I was able to reproduce this issue. But testing older bundles and clean 8.0.4 and 8.5a6 ones work as expected. Thus, closing this as WORKSFORME now barring some good steps to reproduce.

comment:3 Changed 4 months ago by gk

Keywords: noscript tbb-8.0-issues tbb-regression added

Okay, I found a better URL: http://www.worldstarhiphop.com/featured/131466. It seems that the blocking works correctly if the video is not shown because of non-supported video format/MIME type (which is suddenly happening for the original URL) but that might be a coincidence.

However, I feel chances are high this needs to get fixed on the NoScript side... I reproduced the bug with Tor Browser 8.0 as well.

comment:4 Changed 4 months ago by gk

Resolution: worksforme
Status: closedreopened

comment:5 Changed 4 months ago by gk

Description: modified (diff)

comment:6 Changed 4 months ago by boklm

It seems that an http page loading javascript with https using <script src="https://.../"> is correctly blocked. What is not blocked is an https iframe containing scripts, inside an http page.

This can be checked with:
http://test-data.tbb.mars-attacks.org/noscript/https_iframe.html

(for the test to work you first need to visit the https version of the page to add an exception for the self-signed certificate: ​https://test-data.tbb.mars-attacks.org/noscript/https_iframe.html)

comment:7 Changed 4 months ago by ma1

Owner: changed from tbb-team to ma1
Status: reopenedassigned

It should be fixed by [https://github.com/hackademix/noscript/releases/tag/10.2.1rc3 noScript 10.2.1rc3. Please verify, thanks.

comment:8 Changed 4 months ago by ma1

Status: assignedneeds_review

Sorry, messed up the link, it should have been NoScript 10.2.1rc3.

comment:9 Changed 4 months ago by gk

Keywords: TorBrowserTeam201812R added; TorBrowserTeam201812 removed

Works for me, thanks! I'll close this ticket as well once we bump the NoScript version in our build scripts.

comment:10 Changed 4 months ago by ma1

Status: needs_reviewneeds_information

An afterthough: some users are complaining that having TRUSTED subframes constrained by DEFAULT/UNTRUSTED parent document is annoying, if not disfunctional: for instance if you've set Youtube to TRUSTED, embedded movies used to work without the need of raising privileges of the parent page. One may object that you could always use "show only this frame", but do we really have a strong case here for cascading inline restrictions to trusted subdocuments? What's the threat model we're guarding against (beside clickjacking, which is orthogonal to scripting though)?

comment:11 in reply to:  10 ; Changed 4 months ago by gk

Resolution: fixed
Status: needs_informationclosed

Replying to ma1:

An afterthough: some users are complaining that having TRUSTED subframes constrained by DEFAULT/UNTRUSTED parent document is annoying, if not disfunctional: for instance if you've set Youtube to TRUSTED, embedded movies used to work without the need of raising privileges of the parent page. One may object that you could always use "show only this frame", but do we really have a strong case here for cascading inline restrictions to trusted subdocuments? What's the threat model we're guarding against (beside clickjacking, which is orthogonal to scripting though)?

The idea is to defend against malicious exit nodes or other attackers on the wire who want to inject and execute malicious JavaScript despite the user setting the security slider to "safer", which means (among other things) "only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".

E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".

I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.

That said, this bug got fixed with the update to NoScript 10.2.1 on master (commit b32e182633bba7733b635bc5dd0fcbd55436f4d7) and maint-8.0 (commit b35cea6792f294d0a625fde5595f1c96a8a2a72a).

(FWIW: the .xpi on AMO does not have an "an" anymore indicating it works on Android, is that intentional? Diffing 10.2.0 and 10.2.1 I think 10.2.1 should still do its job on Android, too, or am I overlooking something?)

comment:12 in reply to:  11 ; Changed 4 months ago by ma1

Replying to gk:

"only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".

E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".

OK, so as long as this is kept guaranteed (e.g. by checking whether the subdocument has been granted its TRUSTED status by a domain-specific rule or just by the generic "https:", as Tor does, and in the latter case enforcing this "HTTPS only" policy) we're fine, right?

I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.

I'd actually like to at least have a sure-fire mean to tell whether we're running in the Tor Browser or not, in order to enforce special cases which are important for Tor users without affecting the general population.

(FWIW: the .xpi on AMO does not have an "an" anymore indicating it works on Android, is that intentional? Diffing 10.2.0 and 10.2.1 I think 10.2.1 should still do its job on Android, too, or am I overlooking something?)

No it was not intentional, it's just the AMO submission processwhich doesn't default to both platforms being checked anymore, making mistakes like this easier for stable releases, whose submissions cannot be automated :(

Thanks for noticing it!

comment:13 in reply to:  12 Changed 3 months ago by gk

Replying to ma1:

Replying to gk:

"only execute JavaScript loaded over HTTPS provided the URL bar domain got loaded over HTTPS as well".

E.g. it should not be possible that an exit node owner rewrites URLs in a document loaded over HTTP, pointing to malicious JavaScript loaded over HTTPS from a domain they control and getting that JavaScript executed in Tor Browser if the user is on "safer".

OK, so as long as this is kept guaranteed (e.g. by checking whether the subdocument has been granted its TRUSTED status by a domain-specific rule or just by the generic "https:", as Tor does, and in the latter case enforcing this "HTTPS only" policy) we're fine, right?

I think so, yes.

I am fine adding additional code on our side for interacting with NoScript to get that property if that helps you and other users of NoScript who where complaining.

I'd actually like to at least have a sure-fire mean to tell whether we're running in the Tor Browser or not, in order to enforce special cases which are important for Tor users without affecting the general population.

I created #29021 for that.

Note: See TracTickets for help on using tickets.