Opened 5 years ago

Closed 2 years ago

#11624 closed defect (duplicate)

Malicious relays may be able to be assigned Exit flag without exiting anywhere

Reported by: tom Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: needs-proposal, tor-dirauth
Cc: Actual Points:
Parent ID: Points: 4
Reviewer: Sponsor:

Description

The IANA for Multicast addresses indicates there are many /8's that are not yet allocated[0], such as 232.0.0.0-232.255.255.255.

The current voting mechanism in exit_policy_is_general_exit_helper allows an Exit flag to be assigned if it supports exiting to at least one /8 for 2 out of 3 ports of [80, 443, 6667]. exit_policy_is_general_exit_helper calls tor_addr_is_internal, this function only looks for the following IPv4 spaces: 10/8, 0/8, 127/8, 169.254/16, 172.16/12, 192.168/16.

A relay could put one of the unallocated IPv4 blocks and fool the Directory Authorities. Of course, if such a relay really wanted to do this, they could also set their relay up to exit to an uninteresting /8 no one would ever visit, such as one of the many military/DoD /8's.

Zack Weinberg's thread on tor-relays seems to have a good collection of addresses[1]. Other sources are the exclude list from massscan[2] and the IANA registry[3].

This would probably doubly true for IPv6, which only looks for fc00/7, fe80/10, fec0/10 - but right now exit_policy_is_general_exit_helper ignores IPv6.

[0] http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
[1] https://lists.torproject.org/pipermail/tor-relays/2014-April/004431.html
[2] https://github.com/robertdavidgraham/masscan/blob/master/data/exclude.conf
[3] http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

Child Tickets

Change History (29)

comment:1 Changed 5 years ago by cypherpunks

It's possible to allow anything to get exit policy (for any exist or new exit_policy_is_general_exit_helper's rules) while to drop every packet.
What profit to get Exit flag, anyway?

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-final

comment:3 Changed 5 years ago by nickm

Keywords: tor-auth 026-triaged-1 added

comment:4 Changed 5 years ago by teor

Related to #11264, which could reduce the likelihood of this issue, at the risk of adding more corner cases (in its current form, anyway.)

comment:5 Changed 5 years ago by teor

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

The core of this issue appears to be that the Exit flag code is optimistic (just needs a /8 and 2 ports), but the microdescriptor exit policy summary code is pessimistic (needs the entire internet).

We need a proposal to fix the microdescriptor exit policy summary code (and a new consensus method), but the Exit flag could be fixed to be more pessimistic straight away, as it is assigned by authorities.

Perhaps it is easiest to just make one depend on the other?
(A quick fix would be to summarise the exit policy, then use that as input to the Exit flag determination. This would also require a documentation fix.)

comment:6 Changed 5 years ago by teor

Keywords: needs-proposal added

comment:7 Changed 4 years ago by nickm

Status: newassigned

comment:8 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking more tickets as triaged-in for 0.2.7

comment:9 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: unclear
Priority: minornormal
Version: Tor: unspecifiedTor: 0.2.7

comment:10 Changed 4 years ago by nickm

Keywords: PostFreeze027 added

If we wind up with a nice patch for any of these in the appropriate window, we should sure merge it.

comment:11 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

Not expected patches for these by Monday. :(

comment:12 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:13 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Status: assignednew

Turn most 0.2.8 "assigned" tickets with no owner into "new" tickets for 0.2.9. Disagree? Find somebody who can do it (maybe you?) and get them to take it on for 0.2.8. :)

comment:14 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:15 Changed 3 years ago by nickm

Keywords: tor-dos added

comment:16 Changed 3 years ago by nickm

Keywords: tor-dos removed
Sponsor: SponsorU-can

comment:17 Changed 3 years ago by nickm

Points: unclear4
Severity: Normal

comment:18 Changed 3 years ago by isabela

Keywords: isaremoved added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

comment:19 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:20 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:21 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:22 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:23 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:24 Changed 2 years ago by nickm

Keywords: 027-triaged-1-in removed

comment:25 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:26 Changed 2 years ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:27 Changed 2 years ago by nickm

Keywords: isaremoved removed

comment:28 Changed 2 years ago by nickm

Keywords: PostFreeze027 removed

comment:29 Changed 2 years ago by nickm

Resolution: duplicate
Status: newclosed

Closed as duplicate of #1238.

Note: See TracTickets for help on using tickets.