potential bug: Some IPv6Exits do not add the ipv6-policy line to their descriptor

changed milestone to %Tor: 0.2.9.x-final

added 029-backport actualpoints::1 component::core tor/tor ipv6 milestone::Tor: 0.2.9.x-final points::2 priority::medium resolution::fixed severity::major status::closed type::defect version::tor 0.2.4.7-alpha labels

I can't seem to reproduce this issue on any exits or test exits I have.

So here are the log entries I'd like to see from relays with this bug:

Any warnings containing the word "bug"

warnings: Exit policy '%s' and all following policies are redundant Weird family when summarizing address policy policy_dump_to_string ran out of room

info: Unrecognized policy summary keyword Impossibly long policy summary Found bad entry in policy summary Found no port-range entries in summary

debug: Adding new entry Ignored policy Adding a reject ExitPolicy Removing exit policy

To activate debug logging, add "Log debug /path/to/file" to your torrc. Please grep for the relevant log messages, I don't want them all, they are aecurity sensitive.

Trac:
cowcat.torrc

cowcat torrc

Trac:
Cc: N/A to phoul

Milestone to Unspecified. Feel free to change it if this bug is ever figure it out. Thanks!

Trac:
Milestone: N/A to Tor: unspecified

Trac:
Username: rejozenger

rejozenger.torrc

Trac:
Username: rejozenger

In addition to the attached file, I can reach maatuska, tor26, gabelmoo and longclaw over IPv6 (verified by using nmap with -6 -p443). I do not get any error messages when tor is reloaded.

Trac:
Username: rejozenger
Cc: phoul to phoul, rejo@zenger.nl

Replying to rejozenger:

In addition to the attached file, I can reach maatuska, tor26, gabelmoo and longclaw over IPv6 (verified by using nmap with -6 -p443). I do not get any error messages when tor is reloaded.

Are there any messages in your log about creating your descriptor? (Or about accounting limits?)

I can't get a descriptor via http://94.142.242.84/tor/server/authority

Trac:
snowfall.log

I have attached "snowfall.log" which includes debug output mentioned by Teor.

This seems like the kind of bug we should be sure to fix in 0.3.0 if we can; teor and I have been trying to figure out what causes it on IRC tonight. I think we have an idea now.

Trac:
Severity: Normal to Major
Milestone: Tor: unspecified to Tor: 0.3.0.x-final

See my branch bug21357-v2 on https://github.com/teor2345 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 (moved) 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.

Trac:
Keywords: N/A deleted, ipv6 added
Actualpoints: N/A to 1
Status: new to needs_review
Points: N/A to 2
Version: N/A to Tor: 0.2.4.7-alpha

Thanks for the fast bug squashing.

Replying to nickm:

This seems like the kind of bug we should be sure to fix in 0.3.0 if we can;

Please consider also backporting it to 0.2.9.x.

list of potentially (their IPv6Exit setting is unknown to me) affected IPv6 exits by major tor version:

+-------------+------------------+--------+
| tor_version | exit_probability | relays |
+-------------+------------------+--------+
| 0.2.9       |             14.5 |     50 |
| 0.3.0       |              4.4 |     18 |
| 0.2.7       |              3.0 |      8 |
| 0.2.8       |              2.1 |     17 |
| 0.2.5       |              0.4 |      7 |
| 0.2.4       |              0.1 |      1 |
+-------------+------------------+--------+

(the actual numbers can also be higher since I'm only looking at relays with IPv6 ORPort, but you can do IPv6 exiting without IPv6 ORPort)

(I also think this has 0.2.9.x potential.)

Trac:
Keywords: ipv6 deleted, ipv6 029-backport added

In a branch called teor_bug21357-v2_029, I've rebased this onto maint-0.2.9. Testing in chutney on a mixed network now, just to be sure.

Okay, that works. Merged to master and marking for possible backport.

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.2.9.x-final

Replying to cypherpunks:

Thanks for the fast bug squashing.

Replying to nickm:

This seems like the kind of bug we should be sure to fix in 0.3.0 if we can;

Please consider also backporting it to 0.2.9.x.

list of potentially (their IPv6Exit setting is unknown to me) affected IPv6 exits by major tor version: {{{ +-------------+------------------+--------+ | tor_version | exit_probability | relays | +-------------+------------------+--------+ | 0.2.9 | 14.5 | 50 | | 0.3.0 | 4.4 | 18 | | 0.2.7 | 3.0 | 8 | | 0.2.8 | 2.1 | 17 | | 0.2.5 | 0.4 | 7 | | 0.2.4 | 0.1 | 1 | +-------------+------------------+--------+ }}} (the actual numbers can also be higher since I'm only looking at relays with IPv6 ORPort, but you can do IPv6 exiting without IPv6 ORPort)

It is likely that 0.2.8 and later are affected, possible that 0.2.7 is affected, and unlikely that earlier versions are affected.

potential bug: Some IPv6Exits do not add the ipv6-policy line to their descriptor

Child items 0

Activity