Opened 11 years ago

Last modified 7 years ago

#789 closed defect (Fixed)

Improperly bound listen addresses

Reported by: grarpamp Owned by:
Priority: Low Milestone: 0.2.1.x-final
Component: Core Tor/Tor Version: 0.1.2.19
Severity: Keywords:
Cc: nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hi. I have various alias addressing on my interfaces. I mapped
everything to rfc1918 space for this note.

fxp0:

inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
inet 10.0.0.2 netmask 0xffffffff broadcast 10.0.0.2

I fire up a statically compiled tor in a chroot populated with the
minimum required to keep tor quiet:

/etc/resolv.conf
/dev/urandom

I exec tor while already under a dedicated non-root user/group.
I use the following addressing options:

-socksport 9050 -sockslistenaddress 127.0.0.1
-controlport 9051 -controllistenaddress 127.0.0.1
-orport 9001 -orlistenaddress 10.0.0.2
-dirport 9030 -dirlistenaddress 10.0.0.2

Note that my packet filters have proper holes for Tor.

========================================

As you can see, the OR and DIR binds honor the requested use of the
secondary address. Yet the udp and outbound connections bind to the
primary address on the interface.

# before outboundbindaddress
tor tor 55099 4 tcp4 10.0.0.2:9001 *:*
tor tor 55099 5 tcp4 10.0.0.2:9030 *:*
tor tor 55099 6 tcp4 127.0.0.1:9050 *:*
tor tor 55099 7 tcp4 127.0.0.1:9051 *:*
tor tor 55099 8 tcp4 10.0.0.1:1854 86.59.21.38:443
tor tor 55099 12 tcp4 10.0.0.1:1856 128.31.0.34:9001
tor tor 55099 9 udp4 10.0.0.1:3093 w.x.y.z:53
tor tor 55099 11 stream tor[55103]:12
tor tor 55103 9 udp4 10.0.0.1:3093 w.x.y.z:53
tor tor 55103 12 stream tor[55099]:11

So I added this to the config:

-outboundbindaddress 10.0.0.2

Now you can see that this was indeed honored as well. And we are
now left with only the udp binds to deal with. However, I can see
no configuration option to do that.

So that is missing feature #1.

# after outboundbindaddress
tor tor 82854 4 tcp4 10.0.0.2:9001 *:*
tor tor 82854 5 tcp4 10.0.0.2:9030 *:*
tor tor 82854 6 tcp4 127.0.0.1:9050 *:*
tor tor 82854 7 tcp4 127.0.0.1:9051 *:*
tor tor 82854 8 tcp4 10.0.0.2:2601 86.59.21.38:443
tor tor 82854 12 tcp4 10.0.0.2:3605 91.143.80.22:9001
tor tor 82854 9 udp4 10.0.0.1:2228 w.x.y.z:53
tor tor 82854 11 stream tor[82856]:12
tor tor 82856 9 udp4 10.0.0.1:2228 w.x.y.z:53
tor tor 82856 12 stream tor[82854]:11

========================================

Now note that _both_before_and_after_ outboundbindaddress, Tor seems
to be confused regarding its socket allocation as noted below.
Therefore it never publishes its descriptor and I have 384kbits
still sitting useless :-) :-(

So that is bug #2.

[n] Tor v0.2.0.30 (r15956) ... (FreeBSD i386)
[n] Configuration file "/.../etc/tor/torrc" not present, using
reasonable defaults.

[n] Opening OR listener on 10.0.0.2:9001
[n] Opening Directory listener on 10.0.0.2:9030
[n] Opening Socks listener on 127.0.0.1:9050
[n] Opening Control listener on 127.0.0.1:9051

[n] Now checking whether ORPort 10.0.0.1:9001 and DirPort
10.0.0.1:9030 are reachable... (this may take up to 20 minutes
-- look for log messages indicating success)

[w] Your server (10.0.0.1:9001) has not managed to confirm
that its ORPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
[w] Your server (10.0.0.1:9030) has not managed to confirm
that its DirPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.

========================================

Lastly, I think the pairing of:
-<Whatever_function>Port Port
-<Whatever_function>ListenAddress IP[:PORT]

is a bit klunky. In that the pure Port statement is required to
enable the function. But if you also want to bind it somewhere
deterministic you _also_ have to specify the Address IP. And some
functions may be useful to bind more than once in the future. So I
would perhaps see about moving to this style instead:

-<Whatever_function>ListenAddress "{IP|*|#}[:PORT]"

Where '*' means bind to all addresses. And perhaps '#' might refer
to however the current pure Port statement picks its addresses
currently.

========================================

If you're a relay, tor will attempt to do name resolution for
clients, perhaps this is what you're seeing.

Yes. And it should have the facility to bind to whatever address I
tell it to use for that purpose. Not the primary address on any
given interface, the '*' address, etc. Tor already has facilities
for its OR and DIR 'listeners' and the 'outboundbindaddress'. It
needs one one for DNS resolution as well. I don't want it using .1
for that. Create a -dnssrcport and -dnsbindaddress. -dnssrcport
should allow >=1024 for non-root and anything for root, particularly
53.

Note that Tor still performs some tor related DNS queries even if
it is: 'reject *:*'. Otherwise there would be no need to bind udp
in that case.

[w] Your server (10.0.0.1:9001) has not managed to confirm

Because tor can't confirm 10.0.0.1 is a valid non-rfc1918 address.

No. As with w.x.y.z:53, I have protected the innocent for this note.
In your mind, do the reverse and replace every instance of 10.0.0.0/24
above with one publicy routed /24 cidr block while preserving the
last octet. Then it is clear that something is wrong. I have bound
OR, DIR and the 'outboundbindaddress' to .2. It thinks otherwise.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (8)

comment:1 Changed 11 years ago by grarpamp

Hmm...no way to edit bug details.......

comment:2 Changed 11 years ago by grarpamp

Tor seems to be confused regarding its socket allocation as noted below.
Therefore it never publishes its descriptor.

[n] Tor v0.2.0.30 (r15956) ... (FreeBSD i386)
[n] Configuration file "/.../etc/tor/torrc" not present, using
reasonable defaults.

[n] Opening OR listener on 10.0.0.2:9001
[n] Opening Directory listener on 10.0.0.2:9030
[n] Opening Socks listener on 127.0.0.1:9050
[n] Opening Control listener on 127.0.0.1:9051

[n] Now checking whether ORPort 10.0.0.1:9001 and DirPort
10.0.0.1:9030 are reachable... (this may take up to 20 minutes
-- look for log messages indicating success)

[w] Your server (10.0.0.1:9001) has not managed to confirm
that its ORPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
[w] Your server (10.0.0.1:9030) has not managed to confirm
that its DirPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.

Specifying -address .2 along with -orport 9001 -orlistenaddress .2 -dirport 9030
-dirlistenaddress .2 -outboundbindaddress .2 'fixes' this. However these
messages should not appear in the first place when the user has
specified the -OR and -DIR listenaddress .2 details in the config.

Address _address_

The IP address or fqdn of this server (e.g. moria.mit.edu).
You can leave this unset, and Tor will guess your IP address.

It appears to be guessing them wrong and emitting logs as such.

Specifying only -address .2 -orport 9001 -dirport 9030 results
in a *:9001 and *:9030 bind, not an '-address .2' bind. And also
results in some .2:9001 usage. All seen via sockstat.

comment:3 Changed 11 years ago by nickm

Wow, that's a lot of issues!

The "ListenAddress" options affect the address that you're listening on, not the address you advertise. To change the
address you advertise, you need to use the Address option. (These are made separate because lots of people need to
run Tor on a local address, but advertise an external address outside their firewall.) Since you're listening on
address A and Tor is guessing address B, Tor will advertise address B. For your configuration, you probably
want to specify *ListenAddress _and_ Address. I'll read through the documentation again and try to see if I can
figure our any way to make it more clear.

The interface issues are indeed poor, but breaking backward compatibility would suck too. Improving the interface
without breaking compatibility would require some design up front; it would be great to get a Proposal for this.

The UDP thing (where OutboundBindAddress doesn't affect DNS) seems like an actual bug; fixing it will probably require
patching libevent's DNS implementation, but it's the right thing to do. (Using a fixed source port is not a good
idea, in light of the recent Dan Kaminski attacks.)

Are there issues above that I missed?

comment:4 Changed 10 years ago by nickm

Assuming not, since no comment. :)

So the ListenAddress thing is NotABug, and the interface issue needs a feature proposal aimed at 0.2.2.x. See
doc/spec/proposals/001-process.txt for an outline of how our proposal process works.

The only one that's an out-and-out bug is the DNS issue. I've marked this bug as for 0.2.1.x-final for that one.

comment:5 Changed 10 years ago by nickm

I wrote a fix for the OutboundBindAddress thing. It'll wait till 0.2.1.11-alpha, though, since 0.2.1.10-alpha comes
out today and this fix will want a little testing.

comment:6 Changed 10 years ago by nickm

Fix applied. Closing bug.

comment:7 Changed 10 years ago by nickm

flyspray2trac: bug closed.

comment:8 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.