Opened 4 years ago

Closed 4 years ago

#18214 closed defect (not a bug)

exit policy wrongly displayed in globe, atlas etc.

Reported by: toralf Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7.6
Severity: Normal Keywords: security 027-backport 026-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I do have in torrc :

...
# restrict the reduced exit policy here further due to too many abuse tickets from AS (mostly port scans)
#
ExitPolicy reject *:20-21
ExitPolicy reject *:22
ExitPolicy reject *:23
ExitPolicy reject *:80
ExitPolicy reject *:554
ExitPolicy reject *:8000
ExitPolicy reject *:8080

# this is the copy of the reduced exit policy from:  https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
#
ExitPolicy accept *:20-21     # FTP
ExitPolicy accept *:22        # SSH
ExitPolicy accept *:23        # Telnet
ExitPolicy accept *:43        # WHOIS
...

but https://globe.torproject.org/#/relay/F1BE15429B3CE696D6807F4D4A58B1BFEC45C822 shows :

...
reject 173.193.197.194:*
reject *:80
accept *:43
...

This is a remote problem, using stem I do get all rejected ports from my tor process :

ms-magpie ~ # python3 /home/tfoerste/test.py | tr ',' '\n' | grep 'reject \*' | xargs
reject *:20-21 reject *:22 reject *:23 reject *:80 reject *:554 reject *:8000 reject *:8080 reject *:*

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by cypherpunks

Component: OnionooTor

Globe shows exactly what's in the server descriptor, which is indeed strange.

It seems Tor should canonize the port list. In particular, note the:
reject *:80
accept *:80-81

From the current descriptor:
https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-02-02-16-05-32-server-descriptors

router zwiebeltoralf 5.9.158.75 443 0 80
...
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 5.9.158.75:*
reject 217.69.139.160/16:465
reject 94.100.180.160/16:465
reject 85.159.211.119:*
reject 212.71.250.4:*
reject 54.83.43.69:*
reject 192.42.116.41:*
reject 192.42.119.41:*
reject 198.98.103.253:*
reject 208.64.121.161:*
reject 142.0.36.234:*
reject 173.193.197.194:*
reject *:80
accept *:43
accept *:53
accept *:79
accept *:80-81
accept *:88
accept *:110
accept *:143
accept *:194
accept *:220
accept *:389
accept *:464
accept *:465
accept *:531
accept *:543-544
accept *:563
accept *:587
accept *:636
accept *:706
accept *:749
accept *:873
accept *:902-904
accept *:981
accept *:989-990
accept *:991
accept *:992
accept *:993
accept *:994
accept *:995
accept *:1194
accept *:1220
accept *:1293
accept *:1500
accept *:1533
accept *:1677
accept *:1723
accept *:1755
accept *:1863
accept *:2082
accept *:2083
accept *:2086-2087
accept *:2095-2096
accept *:2102-2104
accept *:3128
accept *:3389
accept *:3690
accept *:4321
accept *:4643
accept *:5050
accept *:5190
accept *:5222-5223
accept *:5228
accept *:5900
accept *:6660-6669
accept *:6679
accept *:6697
accept *:8008
accept *:8074
accept *:8082
accept *:8087-8088
accept *:8332-8333
accept *:8443
accept *:8888
accept *:9418
accept *:9999
accept *:10000
accept *:11371
accept *:19294
accept *:19638
accept *:50002
accept *:64738
reject *:*

comment:2 Changed 4 years ago by toralf

funny, the stem libs gives the correct value from local Tor process:

#!/usr/bin/python2 -u
#

import datetime
from stem.control import Controller

def main():
  with Controller.from_port(port = 9051) as controller:
    controller.authenticate()

    policy = controller.get_exit_policy()
    print (policy)

if __name__ == '__main__':
  main()

comment:3 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???
Status: newneeds_information

Can we clarify what the desired behavior is here? I'm afraid I'm not getting it.

Is the problem that the exit policy in your descriptor is not textually identical to what you entered? Tor tries to remove redundant or dead entries from your policy before publishing it.

Is the problem that it could be simplified more?

Or is the problem that the simplification is incorrect somehow?

comment:4 Changed 4 years ago by toralf

I do not speak about the Summary but rather about the full exit policy.
ANd I stumbled over it while reading the line

reject *:80

which doesn't makes sense w/o the preceding "reject <port>" entries -or- is superfluous otherwise.

Last edited 4 years ago by toralf (previous) (diff)

comment:5 Changed 4 years ago by teor

Keywords: security 027-backport 026-backport added
Milestone: Tor: 0.2.???Tor: 0.2.8.x-final
Status: needs_informationnew
Version: Tor: 0.2.7.6

There are two issues here:

tor could simplify descriptors better:

reject *:80
...
accept *:80-81

should become:

reject *:80
...
accept *:81

This issue can be confirmed using globe:
https://globe.torproject.org/#/relay/F1BE15429B3CE696D6807F4D4A58B1BFEC45C822

tor also appears to be leaving some torrc ExitPolicy entries out of the descriptor:

ExitPolicy reject *:20-21
ExitPolicy reject *:22
ExitPolicy reject *:23
...
ExitPolicy reject *:554
ExitPolicy reject *:8000
ExitPolicy reject *:8080

This is a serious security issue if these ExitPolicy entries are not being applied by the relay. On the other hand, if the entries are being applied on the relay, but aren't in the descriptor, it will slow clients down, as they believe the relay will allow ports which it then refuses.

From the stem output, it appears that the ExitPolicy entries are being correctly parsed by tor. But they aren't making it into the descriptor.

toralf, can you confirm if you have sent a HUP to your relay, or restarted the tor process, since changing the config?
Are you only running one tor process?

toralf's relay is running tor 0.2.7.6.

comment:6 Changed 4 years ago by nickm

I agree we could simplify better. Our current simplification logic can only remove a policy A when there is some other B that contains all of A. (And when there is no intervening policy C that makes things more complex -- see exit_policy_remove_redundancies for the full details.) We don't currently combine or split policies even when their port or address ranges would permit this.

But in the second case, I don't think it's a bug. We're leaving those policies out of the descriptor because they are redundant. Consider reject *:20-21 in particular. There's nothing in the policy to say we accept those ports, so reject *:20-21 is completely contained within reject *:* at the end of the policy.

comment:7 Changed 4 years ago by teor

Resolution: not a bug
Status: newclosed

Thanks for the explanation. It makes sense, and the rules are equivalent (and correct).

While we could make redundancy removal more accurate, I'm not sure eliminating this sort of edge case is worth the risk of breakage.

Note: See TracTickets for help on using tickets.