Opened 6 years ago

Last modified 7 weeks ago

#7971 new defect

review address lists in tor_addr_is_internal_()

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client internal-addrs private-address needs-design needs-spec
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

Tor's common/address.c's tor_addr_is_internal_() might be a bit dated, regarding it's list of IANA special-purpose registry, and the IETF RFCs/I-Ds it uses. That code looks for reserved/localhost addresses, and mentions RFCs: 1918, 3879, 4193, and 4291, all of which are outdated.

Yesterday's I-D draft-bonica-special-purpose-06 <http://tools.ietf.org/id/draft-bonica-special-purpose-06.txt> is a list of all of the addresses, which are in RFC5735 (IPv4 addresses) and RFC5156 (IPv6 addresses). The I-D lists 16 addresses for IPv4 and 12 addresses for IPv6.

Tor appears to handle 7 IPv4 addresses (not 16), and 5 IPv6 addresses (not 12); and I don't think one of those (FEC0/10) is shared between the Tor and I-D lists, and might be either a Tor bug or an IETF I-D bug, or my misreading).

Someone who has a better understanding of how Tor uses local addresses, might want to review Tor's code, alongside a current I-D, to see if any of those missing addresses should be added. The I-D has more data than the below tables, so more helpful for deciding.

Tor IPv4 cases:

"0.0.0.0"
"10/8"
"0/8"
"127/8"
"169.254/16"
"172.16/12"
"192.168/16"

I-D IPv4 cases:

"0.0.0.0/8" (RFC 1122: 'This' Network)
"10.0.0.0/8" (RFC 1918: Private-Use)
"100.64.0.0/10" (RFC 6598: Shared Address Space)
"127.0.0.0/8" (RFC 1122: Loopback)
"169.254.0.0/16" (RFC 3927: Link Local)
"172.16.0.0/12" (RFC 1122: Private-Use)
"192.0.0.0/24" (RFC 5736: IETF Protocol Assignments)
"192.0.0.0/29" (RFC 6333: DS-Lite)
"192.0.2.0/24" (RFC 5737: Documentation (TEST-NET-1))
"192.88.99.0/24" (RFC 3068: 6to4 Relay Anycast)
"192.168.0.0/16" (RFC 1918: Private-Use)
"198.18.0.0/15" (RFC 2544: Benchmarking)
"198.51.100.0/24" (RFC 5737: Documentation (TEST-NET-2))
"203.0.113.0/24" (RFC 5737: Documentation (TEST-NET-3))
"240.0.0.0/4" (RFC 1112: Reserved)
"255.255.255.255/32" (RFC 0919: Limited Broadcast)

Tor IPv6 cases:

"::"
"::/127"
"fc00/7"
"fe80/10"
"fec0/10"

I-D IPv6 cases:

"::1/128" (RFC 4291: Loopback Address)
"::/128" (RFC 4291: Unspecified Address)
"::FFFF:0:0/96" (RFC 4291: IPv4-mapped Address)
"0100::/64" (RFC 6666: Discard-Only Prefix)
"2001:0000::/23" (RFC 2928: IETF Protocol Assignments)
"2001:0000::/32" (RFC 4380: TEREDO)
"2001:0002::/48" (RFC 5180: Benchmarking)
"2001:db8::/32" (RFC 3849: Documentation)
"2001:10::/28" (RFC 4843: ORCHID)
"2002::/16" (RFC 3056: 6to4)
"FC00::/7" (RFC 4193: Unique-Local)
"FE80::/10" (RFC 4291: Linked-Scoped Unicast)

Thanks,
Lee

Child Tickets

TicketStatusOwnerSummaryComponent
#5166new198.18.0.0/15 is reserved and in use by home routersCore Tor/Tor
#9426closedmulticast connection triesCore Tor/Tor
#9432closed[PATCH] respect RFC5735 and disallow 'Special Use IPv4 Addresses' per defaultCore Tor/Tor
#28525merge_readyneelMake tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 RangesCore Tor/Tor

Attachments (1)

tor-0.2.4.22-rfc6890.patch (3.9 KB) - added by cypherpunks 5 years ago.
disallow special-purpose address blocks (currently RFC6890)

Download all attachments as: .zip

Change History (18)

comment:1 in reply to:  description Changed 6 years ago by rransom

See also #5166 (and the comments on it) -- fixing this is trickier than it looks.

Replying to cypherpunks:

Thanks,
Lee

Please create a Trac account and start using it.

comment:2 Changed 6 years ago by nickm

Keywords: tor-client added
Milestone: Tor: 0.2.4.x-final

comment:3 Changed 6 years ago by nickm

Keywords: 024-deferrable added

comment:4 Changed 6 years ago by nickm

Summarizing the difficulty from #5166, to see if I understand them.

Adding new addresses that clients will reject as internal when they hear about them is problematic to the extent that it lets you distinguish old clients from new clients.

Adding new addresses that get rejected by "reject private:*" is problematic when clients and servers disagree about what addresses are 'private': If a server rejects an address that a client doesn't expect it to reject, the client will mark the server as a bad exit in 0.2.3 (and under some circumstances in 0.2.4 too). This could be deliberately triggered by a hostile website.

This is a big enough nest of worms that I'm tempted to say that we should do a real solution, and that such a real solution needs to come in 0.2.5. The question remaining is whether _other_ cases of tor_addr_is_internal could change in 0.2.4, and if they did, whether there'd be much real benefit to that.

comment:5 Changed 6 years ago by andrea

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:6 Changed 6 years ago by nickm

Keywords: needs-proposal added
Priority: normalmajor

comment:7 Changed 5 years ago by nickm

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

Changed 5 years ago by cypherpunks

Attachment: tor-0.2.4.22-rfc6890.patch added

disallow special-purpose address blocks (currently RFC6890)

comment:8 Changed 5 years ago by cypherpunks

My motivation of this patch (respect RFC6890) is to deal with local firewall warnings,
and yes it will not fix the problem when different tor versions have different knowledge about special-purpose address blocks.

Respect RFC6890 and disallow special-purpose address blocks.

Data from section
2.2.2. IPv4 Special-Purpose Address Registry Entries
where attribute "Global" set to False

FIXME: for Global N/A definition, needs more clarification

Also disallow multicast destinations because tor don't use multicast.

comment:9 Changed 5 years ago by asn

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

Moving this ticket to 0.2.?? .

A proposal will be required to smoothen the transition and figure out and in what order because we can't do everything at once. Proposal ticket is at #12497.

comment:10 Changed 4 years ago by nickm

Keywords: 024-deferrable needs-proposal removed
Priority: majornormal

Unless I messed up in ticket:12497#comment:4 , this ought to be doable soon, once versions older than 0.2.4.12-alpha are totally gone.

comment:12 Changed 3 years ago by teor

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

Milestone renamed

comment:13 Changed 2 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:14 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 2 years ago by nickm

Keywords: internal-addrs needs-design needs-spec added
Points: 5
Severity: Normal

comment:16 Changed 2 years ago by nickm

Keywords: private-address added

comment:17 Changed 7 weeks ago by cypherpunks

for "100.64.0.0/10" (RFC 6598: Shared Address Space) see #28525

Note: See TracTickets for help on using tickets.