[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21357 [Core Tor/Tor]: potential bug: Some IPv6Exits do not add the ipv6-policy line to their descriptor

#21357: potential bug: Some IPv6Exits do not add the ipv6-policy line to their
descriptor
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.4.7-alpha
 Severity:  Major         |     Resolution:
 Keywords:  ipv6          |  Actual Points:  1
Parent ID:                |         Points:  2
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Changes (by teor):

 * keywords:   => ipv6
 * status:  new => needs_review
 * version:   => Tor: 0.2.4.7-alpha
 * actualpoints:   => 1
 * points:   => 2


Comment:

 See my branch bug21357-v2 on github for a fix to this bug.

 '''Diagnosis'''

 nickm found the bug in policy_summary_reject(), which is called with
 AF_INET when creating microdescriptors and consensuses, and AF_INET6 when
 creating relay descriptors. The code was never written for IPv6.

 This bug was triggered when we started blocking a relay's own IPv6 address
 by default as part of #17027 in 0.2.8.1-alpha. I honestly don't know how
 any IPv6 relay works right now - the one that I operate only works because
 I block a larger IPv6 netblock which includes the relay's address.

 '''Fix'''

 The patch effectively works the same as nickm's, with a few numeric
 adjustments:
 https://paste.debian.net/912059/

 Do we think that an IPv6 /16 is a large enough block to justify a reject?
 (Most providers seem to be allocated a /23, and a /16 is about the same
 proportion of the allocated IPv6 space as a /8 is of all IPv4 space.)

 Is the scaling and saturating arithmetic code sensible?

 Do we need a new consensus method for this?
 I tried very hard to leave the IPv4 behaviour intact, and used non-fatal
 asserts for any errors.

 '''Workarounds'''

 Turning off ExitPolicyRejectPrivate should resolve this issue (it
 automatically rejects the relay's own IPv6 address), but it has security
 implications. Blocking the IPv6 /32 containing your relay's address also
 seems to work, my Exit blocks 3 /32s and functions ok.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21357#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs