Opened 7 years ago

Last modified 17 months ago

#5166 new defect

198.18.0.0/15 is reserved and in use by home routers

Reported by: rransom Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay private-address
Cc: Actual Points:
Parent ID: #7971 Points:
Reviewer: Sponsor:

Description

A user showed up in #tor to ask for help with Tor determining its address incorrectly. Tor published 198.18.0.2 as his/her/its relay's IP address, even though that was not his public IP address.

According to whois, IETF RFC 2544 reserved 198.18.0.0/15:

NetRange:       198.18.0.0 - 198.19.255.255
CIDR:           198.18.0.0/15
OriginAS:
NetName:        SPECIAL-IPV4-BENCHMARK-TESTING-IANA-RESERVED
NetHandle:      NET-198-18-0-0-1
Parent:         NET-198-0-0-0-0
NetType:        IANA Special Use
Comment:        This block has been allocated for use in
Comment:        benchmark tests of network interconnect
Comment:        devices. This range was assigned to
Comment:        minimize the chance of conflict in case a
Comment:        testing device were to be accidentally
Comment:        connected to part of the Internet.
Comment:        Packets with source addresses from
Comment:        this range are not meant to be forwarded
Comment:        across the Internet.
Comment:        This assignment was made by the IETF in
Comment:        RFC 2544, which can be found at:
Comment:        http://www.rfc-editor.org/rfc/rfc2544.txt

Tor should recognize addresses in that netblock as internal.

This is a potential security issue for users who run exit nodes behind screwy home routers which use that netblock for their private addresses.

Child Tickets

Change History (23)

comment:1 Changed 7 years ago by Sebastian

Status: newneeds_review

branch bug5166 in my repo. I did a quick check, I think we don't need to add anything else here.

comment:2 Changed 7 years ago by arma

Quoting myself on irc:

Is the fix that tor should recognize that netblock when it's trying to guess its IP address, and not use it as the external one (as sebastian's bug5166 does)? Or should all exit policies refuse to exit there too? Or just add it to your own exit policy if you find yourself to be using that netblock? Hm.

I am unexcited to add all netblocks that somebody on the internet has used wrongly to the default exit policy.

I expect I'll come to believe that we should in this case, though, since this one is deployed. Yuck.

comment:3 in reply to:  1 Changed 7 years ago by rransom

Replying to Sebastian:

branch bug5166 in my repo. I did a quick check, I think we don't need to add anything else here.

Looks good and correct, for what it is intended to do.

I think we shouldn't merge that patch until we've decided how to block exit attempts to that netblock, though -- otherwise, users will be able to run working relays/exits which will allow connections to LAN IP addresses, which is very bad for their security.

comment:4 Changed 7 years ago by Sebastian

Status: needs_reviewneeds_revision

Oh right. yuck.
from policies.c:

It is important
 *  that all authorities agree on that list when creating summaries, so don't
 *  just change this without a proper migration plan and a proposal and stuff.

comment:5 Changed 7 years ago by Sebastian

(I'm probably not up for making the revisions soon)

comment:6 Changed 7 years ago by nickm

Status: needs_revisionneeds_information

Treating this as an invalid address for address self-discovery seems ok. We need a proposal for more behavior here though.

Do we know what kind of stupid router it is that uses this range?

comment:7 Changed 7 years ago by Sebastian

Identified as zte w300, online docs confirm the usage of 198.18.0.1 as unchangeable router address :/

comment:8 Changed 6 years ago by Sebastian

rransom notes that #5902 is relevant here

comment:9 Changed 6 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

Not security-related; can't make the change in 0.2.2.

For 0.2.3, there is barely enough time to do the minimal version of the change. The minimal version would to re-think Sebastian's patch so that it changes the meaning of "private" for address self-discovery, and for which addresses we will actually connect to. We can't change the public expansion of "private:" without breaking authorities though.

comment:10 Changed 6 years ago by rransom

Status: needs_informationnew

To fix this on the client side, all clients which are running in a LAN which uses this netblock must treat this block as ‘internal’ for the purposes of the ClientRejectInternalAddresses and ClientDNSRejectInternalAddresses options. Thus, all clients must treat this block as ‘internal’ (to avoid making different clients behave differently).

To fix this on the relay/bridge side, a relay which detects that it is running on a computer with at least one interface configured with an IP address in this bogus block would need to (a) learn its address in a different way, if necessary (e.g. if Address isn't explicitly set), and (b) if ExitPolicyRejectPrivate has not been disabled, and the relay's exit policy would otherwise allow exiting to this block, prepend a ‘reject 198.18.0.0/15:*’ line to its exit policy (both locally-enforced and published).

Relays must not refuse to exit to this block unless either (a) all currently-existing Tor clients are unable to connect to the public Tor network, or (b) they publish an exit policy explicitly rejecting this block.

I predict that this ticket will be bumped to 0.2.4.x.

comment:11 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

Throwing this into unspecified. It's a might-do for 0.2.4.x IMO. How prevalent are these horrible nonconformant devices?

comment:12 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:13 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:14 Changed 5 years ago by andrea

Milestone: Tor: unspecifiedTor: 0.2.5.x-final

comment:15 Changed 5 years ago by marek

I cross-checked tor_addr_is_internal_[1] against nmap [2] [3]. Addresses nmap treats as private/unroutable but tor doesn't (comments mostly from nmap):

    6/8         /* USA Army ISC                 */
    7/8         /* used for BGP protocol        */
    55/8       /* misc. U.S.A. Armed forces    */

    224-239/8      /* is all multicast stuff */
    240-255/8      /* is IANA reserved */

    192.0.0/24      /* looks like RFC5736 */
    192.0.2.0/24        /* is reserved for documentation and examples (RFC5737) */
    198.18.0.0/15      /* is used for benchmark tests by RFC2544 */
    198.51.100.0/24  /* is reserved for documentation (RFC5737) */
    203.0.113.0/24    /* is reserved for documentation (RFC5737) */

    192.88.99.0/24    /* is used as 6to4 Relay anycast prefix by RFC3068 */

Additional reference: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

[1] https://github.com/torproject/tor/blob/master/src/common/address.c#L318
[2] https://github.com/nmap/nmap/blob/master/libnetutil/netutil.cc#L445
[3] https://github.com/nmap/nmap/blob/master/nselib/ipOps.lua#L43

comment:16 Changed 5 years ago by rransom

See also #7971.

comment:17 Changed 5 years ago by nickm

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

comment:18 Changed 4 years ago by nickm

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:19 Changed 2 years ago by teor

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

Milestone renamed

comment:20 Changed 22 months 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 17 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:22 Changed 17 months ago by nickm

Keywords: private-address added
Severity: Normal

comment:23 Changed 17 months ago by nickm

Parent ID: #7971
Note: See TracTickets for help on using tickets.