Bug #16694: NoScript is disabled thanks to armagadd-on-2.0

Bug #16694

NoScript is disabled thanks to armagadd-on-2.0

Added by anonym 2019-05-04 07:05:52 . Updated 2019-05-06 18:15:46 .

Status:

Resolved

Priority:

High

Assignee:

Category:

Target version:

Tails_3.13.2

Start date:

Due date:

% Done:

100%

Feature Branch:

feature/16697-upgrade-tor-browser-to-8.0.9-build1

Type of work:

Communicate

Blueprint:

Starter:

Affected tool:

Browser

Deliverable for:

Description

A certificate has expired rendering all Firefox add-ons unsigned. In Tails this is limited to “only” disabling NoScript, which is pretty severe.

We should consider to immediately send our users a security advisory, and we might want to instruct them to xpinstall.signatures.required = False.

Details:

:sajolida:

Subtasks

Feature #16697: Upgrade to Tor Browser 8.0.9-build1

Resolved

100

Related issues

Related to Tails - ~~Bug #16706~~: NoScript gets disabled after a while	Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team	Confirmed

History

#1 Updated by intrigeri 2019-05-04 07:07:37

blocks Feature #16209: Core work: Foundations Team added

#2 Updated by anonym 2019-05-04 07:20:31

Workaround:

echo 'pref("xpinstall.signatures.required", false);' >> \
    ${HOME}/.tor-browser/profile.default/prefs.js

#3 Updated by intrigeri 2019-05-04 07:31:29

Target version set to Tails_3.14

#4 Updated by anonym 2019-05-04 07:57:15

anonym wrote:
> Workaround:
> […]

This only works if executed before Tor Browser has been started for the first time.

Changing the pref inside Tor Button works, because I think some code is hooked that will run if that pref is changed and make some other necessary changes. So the workaround I’ll document will be via about:config.

#5 Updated by anonym 2019-05-04 08:38:51

Status changed from Confirmed to In Progress

Applied in changeset commit:tails|b2e3f48ff1bd29c942827c2e6bb0102ff2fe62d5.

#6 Updated by anonym 2019-05-04 08:42:02

% Done changed from 0 to 10

The advisory is now live.

#7 Updated by sajolida 2019-05-04 11:54:13

Description updated

It’s great that you were here today to act quickly on this emergency problem.

I must say that I’m quite worried about the alarmist tone of the security advisory and would like to understand better the security impact.

The advisory reads “Tor Browser not safe” that I expect most of our less-techsavvy users (eg. our personas) to understand as “non-anonymous anymore”, “can hack into my website accounts”, or even “might compromise my entire Tails”. Are we talking about such things?

My understanding is that the technical implication here is that NoScript is disabled by default.

Without further explanation, our more tech-savvy users (starting with me) might think that, if they don’t use NoScript, it’s not worth bothering with enabling it manually every time.

Going back to our documentation on Tor Browser:

https://tails.boum.org/doc/anonymous_internet/Tor_Browser/#index3h1, Tor Browser itself embeds protection against dangerous JavaScript. Is this protection affected?

https://tails.boum.org/doc/anonymous_internet/Tor_Browser/#index7h1, NoScript is described as a tool to “allow more control over JavaScript, for example, to disable JavaScript completely on some websites”. I also know that NoScript sometimes screams at you whenever it detects suspicious behavior (XSS warnings).

My question to you is: what kind of JavaScript protection NoScript does (on top of Tor Browser, manual NoScript operations, and its screamy warnings) that is disabled now and what concrete security implications does it have for our users. Because I’m afraid that “safe” or “unsafe” and too vague terms to be useful here.

#8 Updated by sajolida 2019-05-04 12:09:53

I did a super quick interview with a Tails user I had nearby after showing her the message on the desktop and the security advisory.

She said that when reading “not safe” it meant that the 2 promises of Tails (anonymity and amnesia) were not guaranteed anymore, 1st in the browser, and 2nd possibly in Tails as a whole. When I asked her about what could happen to the password she uses to log into her mail account, she said it could be hacked.

#9 Updated by anonym 2019-05-04 13:00:05

@sajolida wrote:
> My question to you is: what kind of JavaScript protection NoScript does (on top of Tor Browser, manual NoScript operations, and its screamy warnings) that is disabled now and what concrete security implications does it have for our users.

Basically, I have these same questions. AFAIK no one in FT is available to work on getting the answers today so I’m assuming the worst and worded the advisory to make it clear users must take this action.

> Because I’m afraid that “safe” or “unsafe” and too vague terms to be useful here.

Honestly, the impact is vague, so perhaps it’s actually appropriate? :D Otherwise, how do you think users might make a poor decision, given the current wording?

No matter what, I’m sure wiki/src/security/noscript_disabled_in_tor_browser.mdwn still can use some love. Go wild!

#10 Updated by intrigeri 2019-05-04 13:47:31

> AFAIK no one in FT is available to work on getting the answers today

I could work on this tonight or tomorrow morning. Now, given you (@anonym) took the lead on this so far, I’d rather see you do the FT part of the work, i.e. provide the info that sajolida needs (and then he can then make UX decisions and update the security advisory accordingly).

#11 Updated by anonym 2019-05-04 14:10:07

intrigeri wrote:
> Now, given you (anonym) took the lead on this so far, I’d rather see you do the FT part of the work, i.e. provide the info that sajolida needs (and then he can then make UX decisions and update the security advisory accordingly).

Sorry, I only signed up for getting this advisory out, I’m also busy and probably not available until Monday. :/

#12 Updated by intrigeri 2019-05-04 17:25:59

> Sorry, I […] signed up for getting this advisory out

Then we completely misunderstood each other this morning :/ Reading the log, I can see why: I was not explicit enough and relied on what seemed obvious to me (FT is best at providing technical info, sajolida is best at translating it into user-facing sentences). Sorry!

> I’m also busy and probably not available until Monday

That’s of course totally fine :)

#13 Updated by intrigeri 2019-05-04 17:40:40

Assignee set to intrigeri

As per GeKo on https://lists.torproject.org/pipermail/tor-talk/2019-May/045117.html:

We plan to ship an updated Tor Browser as soon as
Mozilla has fixed the bug on their side. I expect Mozilla to be ready
later today so that we might be able to get a new Tor Browser out
tomorrow, or latest, Monday morning EU time.

So apart of documenting temporary workarounds, we should ask ourselves whether we want+can release Tails 3.13.2 with the fix around May 7, while we have 3.14 scheduled a week later. Regarding “do we want?”: I bet most users won’t re-enable NoScript in practice, regardless of how we document the need for it, so it depends on the security impact analysis, which I’ll do tonight or tomorrow morning (thus assigning to myself). Regarding “can we?”: I personally would have a very hard time RM’ing 3.13.2 but if the Tor Browser release timing is right (tarballs available tomorrow by 17:00 CEST), I can handle the release process until the images are uploaded, and then leave it to someone else to finish.

#14 Updated by intrigeri 2019-05-04 19:11:20

Assignee changed from intrigeri to sajolida

Hi @sajolida! Here are my replies to the questions you asked earlier today. If anything is unclear, I should be able to work on this again tomorrow between 9:00 and 12:00.

First of all, in theory this bug would particularly affect users who set the security slider to a stricter value than the default one; for example, it would prevent disabling JavaScript. But in practice, due to ~~Bug #16613~~, unless they restart Tor Browser after tweaking the security slider, that tweak seems to have no effect on the NoScript configuration; given NoScript implements great parts of the intended effects of higher security slider levels, this point is moot. So below, I’ll focus on the default security slider level (“Standard”).

> The advisory reads “Tor Browser not safe” that I expect most of our less-techsavvy users (eg. our personas) to understand as “non-anonymous anymore”, “can hack into my website accounts”, or even “might compromise my entire Tails”. Are we talking about such things?

I’ll reply to each of those separately, based on the research I’m reporting about below.

> “non-anonymous anymore”

Yes, more easily. One protection that Tor Browser relies on NoScript for is a pretty important anti-fingerprinting measure (making WebGL click-to-play). Without this protection, collaborating web site authors/hosts, providers of shared resources such as JS libraries and remote fonts, and active MitM adversaries (as long as some resource is fetched over plaintext HTTP) can more easily track a given user across the various activities they enjoy in their browser. I don’t know how much more easily.

This attack turns into “non-anonymous anymore” as soon as the affected user uses their “real” (sic) name in the browser. For example, to donate to Tails via PayPal :P

> “can hack into my website accounts”

Yes, more easily. Without the secureCookies, XSS, and CSRF protections usually provided by NoScript, it indeed becomes easier for web site authors/hosts, providers of shared resources such as JS libraries and remote fonts, and active MitM adversaries (with plaintext HTTP) to steal one’s credentials and impersonate them. Properly secured web sites should not be affected but many websites are not properly secured (e.g. our own website still has a rather lax policy; I bet our Redmine has no serious hardening in place against such attacks, so an affected user could be impersonated on this website).

> “might compromise my entire Tails”

No, I don’t think so. I’ve not spotted anything that Tor Browser relies upon NoScript for wrt. hardening vs. arbitrary code execution.

> My understanding is that the technical implication here is that NoScript is disabled by default.

Yes.

> * https://tails.boum.org/doc/anonymous_internet/Tor_Browser/#index3h1, Tor Browser itself embeds protection against dangerous JavaScript. Is this protection affected?

tl;dr: no, it’s not affected, but only part of such protection is implemented directly in Torbutton and Tor Browser; the other part relies on NoScript.

Our text actually says that Torbutton does that. It seems this is entirely obsolete: I can’t find any such thing in current Torbutton, except for security slider levels higher than the default one.

Then I’ve looked at the patches Tor Browser applies on top of Firefox ESR. The only protections I’ve found against attacks that can only happen via JavaScript are:

disable access to some dangerous JavaScript interfaces (320226e62876c3b5a6e80567ca12216155c2d204)
disable javascript.options.asmjs and javascript.options.wasm (see https://2019.www.torproject.org/projects/torbrowser/design/ for details)
setting some prefs so that Tor Browser patches which were upstreamed in Firefox take effect, e.g. first party isolation for a bunch of things, including JavaScript SharedWorkers; that’s about “Identifier Unlinkability Defenses”
lots of fingerprinting protections (HTML5 canvas, fonts)
setting some prefs to disable features that JavaScript could use to fingerprint a user or link activity between websites

> * https://tails.boum.org/doc/anonymous_internet/Tor_Browser/#index7h1, NoScript is described as a tool to “allow more control over JavaScript, for example, to disable JavaScript completely on some websites”. I also know that NoScript sometimes screams at you whenever it detects suspicious behavior (XSS warnings).

NoScript indeed does more than allowing/forbidding JavaScript execution on a per-site/page basis nowadays. It’s become kind of a catch-all place to put hardening measures that can be implemented in an add-on, and that might cause too much trouble for less at risk users.

> My question to you is: what kind of JavaScript protection NoScript does (on top of Tor Browser, manual NoScript operations, and its screamy warnings) that is disabled now and what concrete security implications does it have for our users.

The Tor Browser design doc only mentions NoScript for:

making WebGL click-to-play (to resist fingerprinting)
whatever NoScript does by default; my research suggests this includes mostly the XSS protections you were mentioning (“screamy warnings”, that are definitely poorly exposed to the user, but that are here so that no random website can impersonate you on another website, such as our Redmine)
a bunch of NoScript prefs enable some features; I’ve checked and the relevant ones seem to boil down to:
- secureCookies: avoid leaking cookies set via HTTPS in plaintext later
- ABE: protects against “CSRF and internet-to-intranet attacks”

These features are described in more details in the NoScript FAQ.

Note that NoScript is used a lot more to implement additional protections provided by higher security slider levels; but unfortunately that does not work in Tails 3.13.1, so it’s irrelevant here.

#15 Updated by intrigeri 2019-05-04 19:14:23

Here’s Tor Browser’s blog post about this: https://blog.torproject.org/noscript-temporarily-disabled-tor-browser

#16 Updated by intrigeri 2019-05-04 19:28:24

> So apart of documenting temporary workarounds, we should ask ourselves whether we want+can release Tails 3.13.2 with the fix around May 7, while we have 3.14 scheduled a week later. Regarding “do we want?”: I bet most users won’t re-enable NoScript in practice, regardless of how we document the need for it, so it depends on the security impact analysis, which I’ll do tonight or tomorrow morning (thus assigning to myself).

IMO, the loss of the WebGL click-to-play may warrant an emergency release in itself, if we can afford it, because:

As said above, I doubt most users will follow the recommendations in our security advisory, so many of them will still have NoScript disabled (and if they do follow our recommendations, then they’re exposing themselves to another risk with critical impact, i.e. installing unsigned add-ons, which https://tails.boum.org/security/noscript_disabled_in_tor_browser/ says nothing about → @sajolida, I think this is a serious problem and that advisory should recommend users to not install any add-on while this temporary workaround is active).
https://2019.www.torproject.org/projects/torbrowser/design/ says “After [irrelevant stuff], we believe that the HTML5 Canvas is the single largest fingerprinting threat browsers face today. Studies show that the Canvas can provide an easy-access fingerprinting target: The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graphics library versions allow the adversary to produce a stable, simple, high-entropy fingerprint of a computer. In fact, the hash of the rendered image can be used almost identically to a tracking cookie by the web server. In some sense, the canvas can be seen as the union of many other fingerprinting vectors.”
Thanks to sajolida’s analysis of our last donation campaign, it’s now clear that many Tails users do use Tor Browser in Tails to do stuff with their “real” (sic) name, e.g. donating via PayPal. If they mix this with activities they don’t want to be linked with that name, then WebGL-based fingerprinting becomes really important. Of course, we explicitly state we don’t support mixing several identities in a given Tails session, but in this case I’d rather not hide behind the “it’s unsupported” banner: only documentation says it’s unsupported; the OS itself does nothing to prevent such dangerous practices.

So to me the answer to “shall we release 3.13.2 with the fix?” now boils down to: can we afford it?

#17 Updated by segfault 2019-05-04 20:00:39

> So to me the answer to “shall we release 3.13.2 with the fix?” now boils down to: can we afford it?

I’m available tomorrow, so I could help if there’s anything I can help with

#18 Updated by anonym 2019-05-04 20:01:42

I have only skimmed most of the recent posts, but let me answer this now:

intrigeri wrote:
> So to me the answer to “shall we release 3.13.2 with the fix?” now boils down to: can we afford it?

I can easily afford it, starting Monday. I’m not sure I’ll be online at all until then to coordinate anything, though.

#19 Updated by CyrilBrulebois 2019-05-04 22:49:37

Right now, it seems Mozilla people are still struggling with coming up with suitable patches (already at build3), from my following #tor-devel… If they managed to get a Tor Browser release out in the upcoming hours, I should be able to prepare a tails.git branch against stable. I might be able to put up an emergency release this Sunday if we agree this is what we should do.

#20 Updated by intrigeri 2019-05-05 06:01:26

Summing up our availability:

intrigeri:
> if the Tor Browser release timing is right (tarballs available [on Sunday] by 17:00 CEST), I can handle the release process until the images are uploaded, and then leave it to someone else to finish.

segfault:
> I’m available [on Sunday], so I could help if there’s anything I can help with

anonym:
> I can easily afford it, starting Monday.

kibi:
> I might be able to put up an emergency release this Sunday if we agree this is what we should do.

⇒ It looks like we can afford doing 3.13.2, without anyone having to enter sacrifice mode for an extended period, either by sharing the work among these 4 people, or by letting anonym RM it starting on Monday, depending on when the new Firefox → Tor Browser releases are available. Great! :)

Until we can actually start preparing 3.13.2, personally I’ll relax and get some rest (exhaustion and stress play poorly with RM’ing work), while taking a look every couple hours at the various update channels, in the hope we can glean info there about when we will be able to rush out of the starting blocks.

#21 Updated by intrigeri 2019-05-05 06:13:31

Target version changed from Tails_3.14 to Tails_3.13.2

#22 Updated by intrigeri 2019-05-05 08:51:26

GeKo and boklm started building tbb-8.0.9-build1 1.5h ago. I’ll go offline for a few hours; I should be back around 5pm CEST. If the tarballs are ready earlier and someone else can import them, build, verify the fix works, and run the relevant automated tests, great. Otherwise I’ll do it once I’m back :)

#23 Updated by intrigeri 2019-05-05 16:09:42

(17:15:27) intrigeri: GeKo, boklm: hi! is it worth trying to import boklm's 8.0.9-build1 into Tails, or?
(18:06:47) GeKo: intrigeri: it's the best we have so far, but not tested.
(18:07:01) GeKo: and i don't see any sign of mozilla needing an additional fix
(18:07:23) GeKo: i'll look closer after i am getting back from dinner
(18:07:30) intrigeri: GeKo: thank you :)
(18:07:55) GeKo: (so, to answer your question: yes, i think it is worth it)

I’ll check on XMPP who’s doing this and then they can reassign this ticket to themselves.