Opened 2 years ago

Last modified 15 months ago

#22974 new defect

NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

Reported by: tom Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, noscript
Cc: yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Per #22966 it sounds like NoScript is not signed with a developer key (the 'updateKey' feature described here: https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#updateKey )

updateKey allows the extension developer to require updates be signed with a key only they control. Without it, Mozilla can rewrite extensions and effectively get arbitrary code execution via an add-on.

There's a few things at play here.

1) We could disable add-on updating all together to mitigate this in 52.

2) In 59, when the only 'full' add-ons are 'system' add-ons we'll need to figure this out ourselves anywhere. This will probably involve Tor signing Tor Launcher and TorButton with its own system add-on keys. Dev Tools is an open question.

3) In 59, when Web Extensions are around this won't be as big of a concern. Mozilla can't get code execution but could neuter the effect of an add-on or turn it into spyware (assuming we keep extension updating in place). Whether web extensions will support an updateKey mechanism is an open question (they don't now, EFF wants it. Tor might wish to lend support to the argument. If Tor could get another partner repack to join in that would help even more I bet.)

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by cypherpunks

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:2 in reply to:  description ; Changed 2 years ago by gk

Replying to tom:

Per #22966 it sounds like NoScript is not signed with a developer key (the 'updateKey' feature described here: https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#updateKey )

updateKey allows the extension developer to require updates be signed with a key only they control. Without it, Mozilla can rewrite extensions and effectively get arbitrary code execution via an add-on.

There's a few things at play here.

1) We could disable add-on updating all together to mitigate this in 52.

That's the plan. We'll start with HTTPS-Everywhere (hopefully soon, #10394 is the ticket for that) and do the same with NoScript afterwards.

comment:3 in reply to:  description ; Changed 2 years ago by gk

Replying to tom:

3) In 59, when Web Extensions are around this won't be as big of a concern. Mozilla can't get code execution but could neuter the effect of an add-on or turn it into spyware (assuming we keep extension updating in place). Whether web extensions will support an updateKey mechanism is an open question (they don't now, EFF wants it. Tor might wish to lend support to the argument. If Tor could get another partner repack to join in that would help even more I bet.)

To be honest I am not sure whether we as Tor should push for that. On one hand that allows to add an extra layer of security which is a good thing for all Firefox users but on the other hand do we want to get rid of extension update pinging and extension updating via AMO in our default Tor Browser configuration as a result of the HPKP fiasco (see #20146).

comment:4 in reply to:  2 ; Changed 2 years ago by cypherpunks

Replying to gk:

That's the plan. We'll start with HTTPS-Everywhere (hopefully soon, #10394 is the ticket for that) and do the same with NoScript afterwards.

I'm all for that, but how will you deal with HTTPS-Everywhere ruleset updates? In many cases, some sites may break with HTTPS-E and have subsequent ruleset updates that fix them. With one HTTPS-E update corresponding to a TB release, it would mean that for quiet some time (~2 months) some sites may be broken with TB.

comment:5 in reply to:  4 Changed 2 years ago by gk

Replying to cypherpunks:

Replying to gk:

That's the plan. We'll start with HTTPS-Everywhere (hopefully soon, #10394 is the ticket for that) and do the same with NoScript afterwards.

I'm all for that, but how will you deal with HTTPS-Everywhere ruleset updates? In many cases, some sites may break with HTTPS-E and have subsequent ruleset updates that fix them. With one HTTPS-E update corresponding to a TB release, it would mean that for quiet some time (~2 months) some sites may be broken with TB.

Yes, which is why we did not do that step yet. HTTPS-Everywhere will have a ruleset updater. Once this is ready we'll stop letting HTTPS-Everywhere update itself once a new version is out.

comment:6 Changed 2 years ago by cypherpunks

FF57 is just right around the corner (a week) and it may be time to lock the NoScript update with the next TB update since: https://forums.informaction.com/viewtopic.php?f=7&t=23173&start=30#p90133

Unfortunately some APIs have been deferred by the Firefox team to 58.
NoScript will be released as a WebExtension for Firefox 57 with all the major functionalities but some limitations (mostly related to features used by the Tor Browser, which require the still missing APIs), while feature parity with "legacy" NoScript will be guaranteed only when the Tor Browser gets its next major upgrade, i.e. in March 2018 when it will be based on Firefox 59.

comment:7 in reply to:  3 Changed 17 months ago by cypherpunks

Keywords: tbb-security added

Replying to gk:

we want to get rid of extension update pinging and extension updating via AMO

Done with NoScript Classic.

in our default Tor Browser configuration as a result of the HPKP fiasco (see #20146).

But check what happens now, heh...

comment:8 Changed 15 months ago by traumschule

Keywords: noscript added
Note: See TracTickets for help on using tickets.