Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10464 closed defect (fixed)

TBB3.5's NoScript allows addons.mozilla.org even when scripts are globally forbidden

Reported by: torar Owned by: erinn
Priority: High Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: MikePerry201312
Cc: gk, mikeperry Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description

Hi

There's a bug in NoScript: If the user clicks on "Forbid Scripts Globally", scripts are disabled, except for one site: addons.mozilla.org. This site was automatically added to the NoScript whitelist.

Note that this bug has security implications - a malicious exit node can redirect the user to addons.mozilla.org and then return any fake data (including some 0-day javascript exploit) as content of addons.mozilla.org. Thus, the user is vulnerable to javascript exploits, even if the user disables javascript by clicking on "Forbid Scripts Globally".

There are other URLs in the whitelist, starting with about:, blob:, chrome:, resource: - they are hopefully not exploitable, but you should it check anyway - can, for example, some malicious site redirect the user to one of these whitelist URLs and use cross-site-scripting to run some javascript? I don't know.

Please patch the NoScript add-on in the Tor Browser Bundle, so that it has empty whitelist.

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by arma

Cc: gk mikeperry added

This does indeed seem important!

comment:2 Changed 4 years ago by arma

Summary: A security bug in NoScript in Tor Browser BundleTBB3.5's NoScript allows addons.mozilla.org even when scripts are globally forbidden

comment:3 Changed 4 years ago by mikeperry

Ah crap. This should be https://addons.mozilla.org at the very least.

On the one hand, if javascript is disabled on a.m.o, I think that addons cannot be verified (because they are downloaded over http, but verified with JS sourced from https://addons.mozilla.org). On the other hand, due to the weak pinning (I believe only the common name of the CA is pinned), maybe even https://addons.mozilla.org is too much to default whitelist?

comment:4 Changed 4 years ago by arma

So the clear bug is that we whitelist http://a.m.o and we should totally fix that.

The harder tradeoff apparently is that if we allow https://a.m.o then a bad guy who can get an ssl cert can still give you javascript. But if we *don't* allow https://a.m.o, then if the user installs a new addon, Firefox won't check its integrity at all.

It seems to me that 'Forbid scripts globally' is crystal clear about what you've asked it to do.

Is there a way to warn a user who has javascript disabled and tries to install a new addon?

If the user goes to about:config and turns javascript off manually, does this mean they no longer check integrity of new addons? (For added excitement, the new addons are fetched via http, because that's just how Firefox works.)

comment:5 Changed 4 years ago by mikeperry

Keywords: MikePerry201312 added
Points: 0.5
Resolution: fixed
Status: newclosed

Ok. In origin/master, I removed the addons.mozilla.org entry entirely. "Fully disable scripts" probably should mean exactly that. This fix should appear in 3.5.1.

comment:6 Changed 4 years ago by arma

"Is there a way to warn a user who has javascript disabled and tries to install a new addon?"

comment:7 Changed 4 years ago by mikeperry

I just tested a.m.o again and it does appear to be using https urls exclusively now. It also presents different download buttons if JS is disabled. I assume this now means they are trying to keep the non-JS case both supported and secure.

comment:8 Changed 4 years ago by arma

That's great news!

Are there any other things that check with javascript.disabled is true, vs whatever Noscript does? That is, what's the next edge case we're going to discover where doing this via noscript turns out to not quite be the same?

Note: See TracTickets for help on using tickets.