[tor-bugs] #1859 [Tor Client]: Using 'mytorexitnode.exit' request when mytorexitnode is both exit and client

[Tor Bug Tracker & Wiki]

#1859: Using 'mytorexitnode.exit' request when mytorexitnode is both exit and
client
------------------------+---------------------------------------------------
 Reporter:  mwenge      |       Owner:                     
     Type:  defect      |      Status:  needs_review       
 Priority:  normal      |   Milestone:                     
Component:  Tor Client  |     Version:  Tor: 0.2.2.12-alpha
 Keywords:              |      Parent:                     
------------------------+---------------------------------------------------

Comment(by mwenge):

 Replying to [comment:3 Sebastian]:
 > So here's my idea for a patch. I'm not sure if that can break in other
 cases, but it fixes the problem.
 >
 > {{{
 > diff --git a/src/or/routerlist.c b/src/or/routerlist.c
 > index 8808f56..f8b2b65 100644
 > --- a/src/or/routerlist.c
 > +++ b/src/or/routerlist.c
 > @@ -2408,12 +2408,16 @@ router_get_by_hexdigest(const char *hexdigest)
 >  routerinfo_t *
 >  router_get_by_digest(const char *digest)
 >  {
 > +  routerinfo_t * res = router_get_my_routerinfo();
 > +
 >    tor_assert(digest);
 >
 >    if (!routerlist) return NULL;
 >
 >    // routerlist_assert_ok(routerlist);
 >
 > +  if (res && !memcmp(res->cache_info.identity_digest, digest,
 DIGEST_LEN))
 > +    return res;
 >    return rimap_get(routerlist->identity_map, digest);
 >  }
 >
 > }}}

 I had:

 {{{
 diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c
 index e5e7d22..4f75a6d 100644
 --- a/src/or/circuitbuild.c
 +++ b/src/or/circuitbuild.c
 @@ -3176,6 +3176,9 @@ build_state_get_exit_router(cpath_build_state_t
 *state)
  {
    if (!state || !state->chosen_exit)
      return NULL;
 +
 +  if (router_digest_is_me(state->chosen_exit->identity_digest))
 +    return router_get_my_routerinfo();
    return router_get_by_digest(state->chosen_exit->identity_digest);
  }
 }}}

 which does the same I think. One odd problem I encountered was that,
 although it fixed the circuit-building DOS, it resulted in a circuit being
 chosen with the wrong exit. Tor had tried to build a four-hop circuit with
 my Tor instance as the exit but the patch resulted in it using a three-hop
 circuit exiting somewhere else.

 I believe this is what yetonetime is alluding to. At least
 connection_ap_can_use_exit() relies on the presence of the exit in the
 routerlist with:

 {{{
     routerinfo_t *chosen_exit =
       router_get_by_nickname(conn->chosen_exit_name, 1);
 }}}

 It looks to me like supporting the scenario in the bug is a bit of a
 losing battle. Tor should probably fail gracefully I think and we don't
 have a patch for that yet.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1859#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online