Opened 6 years ago

Closed 6 years ago

#10682 closed defect (fixed)

Disable update pings for Torbutton and Tor Launcher

Reported by: mikeperry Owned by: mikeperry
Priority: Very High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: tbb-security, extdev-interview, MikePerry201401R
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Bobnomnom reports that it is currently possible to hijack addon updates of Torbutton and TorLauncher by submitting a fake version to addons.mozilla.org with a matching addon uid. Because both of these addons lack an update url, they both still ping addons.mozilla.org for updates to their addon ID. Mozilla reviewers might catch an attempt by a rogue addon upload that is trying to steal our ID and do bad things, but then again they might not.

It used to be possible to disable individual addon updates by creating a pref for extensions.{id}.updates.enabled, but I think this has now changed. There still is a mechanism for it though. The addons UI has a "More..." link for each addon that opens a pane where you can click a radio button to disable updates for that addon. It does not appear to set any prefs though.

We need to investigate what this UI is doing now and set the equivalent value somehow ourselves.

Child Tickets

Attachments (1)

0001-Ticket-10682-Set-dummy-update-URL-to-prevent-AMO-hij.patch (970 bytes) - added by zyan 6 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 6 years ago by gk

Cc: gk added

comment:2 Changed 6 years ago by cypherpunks

#10501 is related.

comment:3 Changed 6 years ago by gk

Disabling the ping is not so easy it turns out. The radio button you are alluding to just disables the auto-install of an update which gets fetched though, if available. (btw that pref is directly saved into the extensions.sqlite database (applyBackgroundUpdates)). If we already want to prevent the ping (which is a good idea IMO) we could just give Torbutton and TorLauncher a custom update URL pointing to our servers (and returning nothing) or just to 127.0.0.1. Not sure if the latter works at all but it might be the best solution if we avoid unnecessary update traffic in the first place.

comment:4 Changed 6 years ago by mikeperry

Keywords: extdev-interview added

comment:5 Changed 6 years ago by zyan

Hi! Made a quick patch to set updateURL to https://127.0.0.1 (FF doesn't let you install addons with protocol-less or HTTP updateURLs, it seems). Verified expected results with tshark on port 443 before/after applying the patch while manually forcing an update (right click on the addon in about:addons).

Anything other tests I should run?

comment:6 Changed 6 years ago by zyan

That patch is for Torbutton; presumably should work for both if it works for either.

comment:7 Changed 6 years ago by mikeperry

Keywords: MikePerry201401R added
Status: newneeds_review

comment:8 Changed 6 years ago by cypherpunks

FF doesn't let you install addons with protocol-less or HTTP updateURLs, it seems

Why we need install addons? What happens if to use TBB with already "installed" such addons? If you tries to solve problem by breaking some functional then probably using TBB with updateURL that breaking any tries to fetch would be better?

comment:9 Changed 6 years ago by cypherpunks

What happens if to use TBB with already "installed" such addons?

Found answer. It disables addon.

comment:10 Changed 6 years ago by cypherpunks

Then if to fetch (even for localhost, it still fetches) something then probably protect it by large enough broken update key.

comment:11 Changed 6 years ago by cypherpunks

broken update key.

and yet to use banned port

<em:updateURL>https://127.0.0.1:9050/</em:updateURL> 

banned_ports affects it?

comment:12 Changed 6 years ago by ben

Set pref "extensions.logging.enabled" to true, and look at the Firefox menu | Developer | Browser Console.
Note, though, that SSL cert errors will not show up anywhere - that's a Firefox bug.

comment:13 Changed 6 years ago by cypherpunks

Status: needs_reviewnew

Break updates properly or nothing. It's better to fetch from AMO, at least guids blocked right now, than to fetch from unknown place for real.

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

comment:14 Changed 6 years ago by mikeperry

Well, due to the fix for #10419, these requests are in fact broken. The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node, unless the user edits their torrc to set 'ExtendAllowPrivateAddresses 1' for some reason. So this should certainly be an improvement

If you want defense in depth against people who reconfigure Tor/Firefox, we can also use a banned port too instead of 443, but this fix is already in 3.5.2, which we shouldn't delay any further without compelling reason because it contains security fixes for Firefox 24.3.0.

Would you consider a banned port to be an improvement? If so, we can file a new ticket and I will commit that immediately for 3.5.3.

comment:15 Changed 6 years ago by ben

How about https://127.0.0.1:0 ? In my standard Firefox, 0 seems to be a banned port.
I concur with cyberpunks that it's better to use a wrong port than a real one.

comment:16 Changed 6 years ago by cypherpunks

fix for #10419

Security hole.

ExtendAllowPrivateAddresses

no. ClientRejectInternalAddresses

The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node

It's all depends Tor not Torbrowser that has security hole with passing localhost over proxy.

comment:17 Changed 6 years ago by cypherpunks

https://127.0.0.1:0

TBB not get it like valid URL, passing it to search engine.

comment:18 in reply to:  16 Changed 6 years ago by mikeperry

Replying to cypherpunks:

fix for #10419

Security hole.

Can you explain how this fix is a security hole?

ExtendAllowPrivateAddresses

no. ClientRejectInternalAddresses

Sorry, pasted the server side option. But it is still blocked by the Tor client by default.

The browser will no longer connect to directly to 127.0.0.1, nor will connections to 127.0.0.1 be sent to the exit node

It's all depends Tor not Torbrowser that has security hole with passing localhost over proxy.

Fair enough, I guess if people want to extend Tor Browser to support other SOCKS proxies, I would not refuse patches that made that more secure or functional. But it is not a development priority at this point for us to do this.

It also sounds like you are now asking for an additional patch that completely blocks 127.0.0.1 from the browser independent of addon update URLs? Should we also extend that patch to block all RFC1918 addresses from the browser, too? This definitely sounds like a separate ticket.

https://127.0.0.1:0

TBB not get it like valid URL, passing it to search engine.

There are banned ports that are hardcoded in Firefox, like 25. Should we use one of those instead?

Last edited 6 years ago by mikeperry (previous) (diff)

comment:20 Changed 6 years ago by cypherpunks

Can you explain how this fix is a security hole?

Communicating with localhost over proxy is security hole.
Torbrowser not Tor. It's ok Tor client prevents localhost connection attempts, but this have nothing with browser security. You patches browser for dns leaks but why if user could to use tails or netfilter? Because design of Torbrowser.

comment:21 Changed 6 years ago by ben

I think cypherpunks is worried that for whatever reason (bug, misconfiguration, etc.), Tor might actually answer on that https://localhost:9050/ request - and somehow allow an attacker to deliver an XPI, which will then be installed. For that to happen, Tor would need to speak SSL and present a proper cert (signed by a CA that Firefox has built in).
I think the chance of all that coming together is almost nil, but I agree that it's safer to use a port where no server is listening.

Last edited 6 years ago by ben (previous) (diff)

comment:22 Changed 6 years ago by ben

While we're at it, I think it's safer to do the same for all extensions that are shipped with Tor, including HTTPS Everywhere and noscript. If I'm coming out of an tor exit node asking for an update for my noscript, that's an easy way to get me. The SSL certs are checked, but I think all built-in CAs are accepted by Firefox.

comment:23 Changed 6 years ago by zyan

HTTPS Everywhere already has an updateURL and updateKey, since EFF self-hosts it.

comment:24 Changed 6 years ago by ben

Ah, indeed, an updateKey is more secure than simple SSL with CAs. <https://developer.mozilla.org/de/docs/McCoy>
noscript (coming with my TBB) doesn't have an updateURL, though, so it would update via AMO (addons.mozilla.org), which means the security of Tor users depends on AMO infrastructure.

Last edited 6 years ago by ben (previous) (diff)

comment:25 Changed 6 years ago by gk

Resolution: fixed
Status: newclosed

This is fixed in 19f7e22728e9ec5adcc8852a85a234efd2cbbf1e for Torbutton and in 7994ee0d77d609d8f692675147a7fcf32c0301b8 for TorLauncher.

Note: See TracTickets for help on using tickets.