[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