Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#3296 closed defect (fixed)

Exitnode that can't handle a predicted port -> endless circuit creation

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I set "exitnode cherrybomb" on my maint-0.2.2:

May 26 17:52:38.802 [notice] All routers are down or won't exit -- choosing a doomed exit at random.
May 26 17:52:39.493 [notice] All routers are down or won't exit -- choosing a doomed exit at random.
May 26 17:52:39.689 [notice] All routers are down or won't exit -- choosing a doomed exit at random.
May 26 17:52:39.810 [notice] All routers are down or won't exit -- choosing a doomed exit at random.
...

Looking in more detail at the logs, I see

May 26 17:52:17.061 [debug] circuit_remove_handled_ports(): Port 5222 is not handled.

My pidgin wanted to talk AIM, but my exitnode doesn't allow 5222.

A 'getinfo circuit-status' on the control port showed scores of circuits all ending at cherrybomb.

Tor should ignore predicted ports for destinations its configured exit nodes can't handle, rather than making an infinite pile of circuits that wouldn't be able to handle the requests anyway.

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by arma

See also #1288 for a bug that may or may not be related.

comment:2 Changed 7 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

This doesn't seem to be a problem lots of folks are running into; we can try to fix it in 0.2.3.x, but it's not worth the risk of destabilizing 0.2.2.x to backport a fix there.

comment:3 Changed 7 years ago by nickm

Status: newneeds_review

So afaict the issue is that we are checking whether all predicted ports are handled, when what we should be checking is whether all predicted ports are either handled or unhandleable.

One possibility would be, if we ever reach the end of the "for (attempt = 0; attempt < 2; attempt++)" loop in choose_good_exit_server_general, to tell rephist that the remaining predicted ports are unsupportable, and to remove them entirely. Does that work here?

If so, see branch "bug3296" in my public repository.

(But consider that in the example you give, for us to get the "doomed exit at random" message, *every* exit needs to have n_supported == -1, right? So if you're seeing that one, not only is it hopeless to build a circuit to cherrybomb for 5122; it is also hopeless to try to build a circuit at all, I think. Could that be another bug?)

comment:4 Changed 7 years ago by arma

This could become an exploitable bug: if there were ever a port that isn't supported by the default set of exit relays, you could induce clients to go berserk by including an img link to http://foo:25 in a page they visit. I wonder if you could even use it as-is to probe your client's ExitNodes setting. Not quite enough of an argument to reconsider 0.2.2 imo, but figured I should raise it.

comment:5 in reply to:  3 Changed 7 years ago by arma

Replying to nickm:

If so, see branch "bug3296" in my public repository.

Your branch seems to work ok. But:

(But consider that in the example you give, for us to get the "doomed exit at random" message, *every* exit needs to have n_supported == -1, right? So if you're seeing that one, not only is it hopeless to build a circuit to cherrybomb for 5122; it is also hopeless to try to build a circuit at all, I think. Could that be another bug?)

You're right, in this case we're launching a new circuit, repeatedly, when we really ought to be telling the stream to fail. This whole 'doomed exit' thing was supposed to improve our robustness during edge cases. But I think it just leads to sadness. Hm.

comment:6 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final

Merging bug3296, and putting this into 0.2.2.x as possibly backportable.

I'm opening a new ticket for the doomed exit business.

comment:7 Changed 7 years ago by nickm

The new ticket is now #5902.

comment:8 Changed 7 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.4.x-final

comment:9 Changed 7 years ago by rransom

Milestone: Tor: 0.2.4.x-finalTor: 0.2.3.x-final
Resolution: fixed
Status: needs_reviewclosed

comment:10 Changed 7 years ago by nickm

Keywords: tor-client added

comment:11 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.