Opened 2 years ago

Last modified 7 months ago

#20212 new enhancement

Tor can be forced to open too many circuits by embedding .onion resources

Reported by: gacar Owned by: tbb-team
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: guard-discovery, TorBrowserTeam201803, 034-roadmap-proposed, security, tor-hs
Cc: gk, mcs, brade, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A malicious web page or an exit node* can force Tor to open too many new circuits by embedding resources from multiple .onion domains.

I could observe up to 50 new circuits per second, and a total of a few hundred circuits in less than a half minute.

The embedded HS domains don't need to exist, Tor will still open an new internal circuit for each .onion domain to download the descriptors.

I guess forcing clients to make too many circuits may enable certain attacks, even though the circuits are internal.

Maybe Tor (or Tor Browser) could cap the number of new circuits opened within a time window. I can't think of a realistic use case for loading resources from tens of different hidden services.

*: only when the connection is unencrypted HTTP

Child Tickets

TicketTypeStatusOwnerSummary
#25609defectnewInvestigate Tor client retry behavior on failing onions

Change History (18)

comment:1 Changed 2 years ago by gk

Cc: gk added

comment:2 Changed 21 months ago by nickm

Component: Core Tor/TorApplications/Tor Browser
Owner: set to tbb-team

I can't think of a solution here that isn't imposing an upper limit on the total number of .onion hostnames referenced from one page?

comment:3 in reply to:  description Changed 21 months ago by teor

Replying to gacar:

Maybe Tor (or Tor Browser) could cap the number of new circuits opened within a time window. I can't think of a realistic use case for loading resources from tens of different hidden services.

Here are two:

  • Checking the status of many hidden services
  • CDNs or other load-balancing techniques

comment:4 Changed 15 months ago by gacar

Keywords: guard-discovery added

comment:5 Changed 13 months ago by mikeperry

Milestone: Tor: unspecified

Unlike the generic or custom-built Tor client case (CDNs and status pingers will likely customize their Tor client for performance), Tor Browser specifies a SOCKS username and password for url bar domain isolation. When this u+p is set, we should be able to safely limit the number of onion hostnames for a single SOCKS username + password to some low number (5? 10?).

Do we need a separate limit if third party hidden services are malicious and deliberately fail either HSDIR, IP, or RP attempts in a way that causes the client to retry them? Maybe there should be a total rend circuit limit per SOCKS u+p?

comment:6 Changed 8 months ago by asn

How should we proceed here? Leif suggested we introduce a Max3rdPartyOnions option to limit the number of onion addresses that an origin is allowed to cause the browser to make connections to.

Do we think this is a reasonable approach? And what should the default value be? Can we add this to our TB roadmap in some capacity?

Last edited 8 months ago by asn (previous) (diff)

comment:7 in reply to:  6 ; Changed 8 months ago by gk

Replying to asn:

How should we proceed here? Leif suggested we introduce a Max3rdPartyOnions option to limit the number of onion addresses that an origin is allowed to cause the browser to make connections to.

Do we think this is a reasonable approach? And what should the default value be? Can we add this to our TB roadmap in some capacity?

You mean this should be fixed on the browser side? It seems to me having a patch in tor makes more sense.

comment:8 in reply to:  7 ; Changed 8 months ago by gk

Cc: mcs brade added
Keywords: TorBrowserTeam201803 added

Replying to gk:

Replying to asn:

How should we proceed here? Leif suggested we introduce a Max3rdPartyOnions option to limit the number of onion addresses that an origin is allowed to cause the browser to make connections to.

Do we think this is a reasonable approach? And what should the default value be? Can we add this to our TB roadmap in some capacity?

You mean this should be fixed on the browser side? It seems to me having a patch in tor makes more sense.

After some more discussion happened, let's try to fix that on the browser side (first). mcs/brade: can you look into it?

comment:9 Changed 8 months ago by cypherpunks

Why limit the number of onion addresses that can be embedded instead of limiting the number of circuits that can be created for onions in a single origin?

comment:10 in reply to:  9 ; Changed 8 months ago by cypherpunks

Replying to cypherpunks:

Why limit the number of onion addresses that can be embedded instead of limiting the number of circuits that can be created for onions in a single origin?

The former should be relatively easy to implement in Tor Browser, while the latter would presumably be much more difficult and error prone (if implemented by monitoring circuit events on the control port). The simple approach of limiting the number of onions seems like it would indirectly limit the number of circuits, but reading the above question I'm suddenly having doubts. (How quickly can Tor Browser cause more circuits to be made by continually retrying just one onion that is failing to rendezvous?)

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

Replying to cypherpunks:

Replying to cypherpunks:

Why limit the number of onion addresses that can be embedded instead of limiting the number of circuits that can be created for onions in a single origin?

The former should be relatively easy to implement in Tor Browser, while the latter would presumably be much more difficult and error prone (if implemented by monitoring circuit events on the control port). The simple approach of limiting the number of onions seems like it would indirectly limit the number of circuits, but reading the above question I'm suddenly having doubts. (How quickly can Tor Browser cause more circuits to be made by continually retrying just one onion that is failing to rendezvous?)

Good question. I think we can spend some time figuring that out so we can come up with a good plan for fixing this bug.

comment:12 in reply to:  8 Changed 8 months ago by mcs

Replying to gk:

After some more discussion happened, let's try to fix that on the browser side (first). mcs/brade: can you look into it?

Yes, we can take a look. It would be helpful to develop a better understanding of what kind of attack(s) we are trying to prevent. That might lead to a better design. For example, do we want to limit the rate at which new circuits can be opened or do we just want to refuse to open more than N circuits per site? Unfortunately, Kathy and I don't really know enough about tor and the Tor Network to do that kind of analysis, so hints about what should be done would be greatly appreciated.

comment:13 Changed 8 months ago by asn

Here is another attack from IRC arma: An attacker could also setup an onion address that redirects you to another onion address which redirects you to another onion address ad infinitum. This allows the attacker to cause n onion loads in series, and if each page has k onions, this allows attacker to cause n*k onion loads. That's both an optimization but is also meant to work around any defences that try to restrict onion address loads per origin.

Furthermore, depending on how stream isolation works, the above attack could also work with IPs/domain addresses and not just onions.

comment:14 in reply to:  10 Changed 8 months ago by asn

Replying to cypherpunks:

Replying to cypherpunks:

Why limit the number of onion addresses that can be embedded instead of limiting the number of circuits that can be created for onions in a single origin?

The former should be relatively easy to implement in Tor Browser, while the latter would presumably be much more difficult and error prone (if implemented by monitoring circuit events on the control port). The simple approach of limiting the number of onions seems like it would indirectly limit the number of circuits, but reading the above question I'm suddenly having doubts. (How quickly can Tor Browser cause more circuits to be made by continually retrying just one onion that is failing to rendezvous?)

I opened #25609 to investigate the issue presented in the last parenthesis of this post. It's important because if an attacker can cause Tor to make many circuits by continuously retrying a broken onion, this can bypass any sort of origin rate-limiting defense.

comment:15 Changed 8 months ago by asn

Component: Applications/Tor BrowserCore Tor/Tor

comment:16 Changed 8 months ago by asn

Keywords: 034-roadmap-proposed security added

comment:17 Changed 7 months ago by dmr

Cc: dmr added

comment:18 Changed 7 months ago by dmr

Keywords: tor-hs added
Note: See TracTickets for help on using tickets.