ID: 446PHID: PHID-TASK-p6abrrzk7pgekzkzulfqAuthor: PatrickStatus at Migration Time: resolvedPriority at Migration Time: Normal
We now have control port filter proxy whiltelist wildcard support. (T445)
(Variable CONTROL_PORT_FILTER_ALLOW_WILDCARDS. It’s disabled by default, but by the time it gets enabled for example by users on onionshare or ricochet, we need to know about the security implications.)
This ticket is for researching the security implications.
If we whilte listed the wildcard add_onion *, we don’t want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address.
To be researched, if Tor’s control protocol actually supports something like ;. If it does, then this would complicate the wildcard feature.
(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands.)
Tor Control Protocol description:https://gitweb.torproject.org/torspec.git/tree/control-spec.txt
2015-12-05 20:31:46 UTC
I don’t think we should ever add a wildcard feature it seems very risky. Even if there are no dangerous Tor HS commands now this may change in the future. The point of a whitelist was to prevent the problem of unforeseen extensions to the protocol having negative security implications.
The safest option is to hardcode the ports needed by any Tor based software we want to support and to only enable this subset of the whitelist when a user explicitly switches on a boolean on the Gateway.
2015-12-06 13:10:10 UTC
No wildcard feature would almost equal a wontfix for Ricochet (T444), onionshare, and potentially other software (bitcoin, globaleaks, securedrop).
It’s not just about the port number. That would be too simple.
See https://gitweb.torproject.org/torspec.git/tree/control-spec.txt and have a look at the syntax of the ADD_ONION Tor control protocol command. The command will be used by Ricochet / onionshare / etc. to create a Tor hidden service without using the file system. I.e. not using /var/lib/tor on the gateway to store the hidden service key.
Example:
ADD_ONION RSA1024:cryptographic-key-long-blob-of-binary-data Port=80,192.168.1.1:8080
2015-12-07 14:55:14 UTC
I see. Then as long as wildcards can be safely implemented even if something like ; is around it should be OK.
What about the other point about making this part of the whitelist need activation by the user? The idea is for defense in depth so only some of the users would be affected in the unlikely chance there is something instead of all Whonix installations.
2015-12-07 15:03:38 UTC
HulaHoop (HulaHoop):
What about the other point about making this part of the whitelist
Yes.
(At time of writing, none of the tickets does argue about allowing
A related point is, if adding a Tor hidden service from a compromised
2015-12-31 18:29:54 UTC
After looking at the spec I think the protocol has the ; equivalent CRLF. Carriage Return and Line Feed signifying newline. \n \t \r and \0 … \377 are treated as C escapes (Section 2 is of interest).
Also relevant is multiline commands support with ‘+’ characters.
I think these could allow combining different commands with negative effects we are trying to block.
2016-01-02 22:30:54 UTC
2016-01-03 15:31:39 UTC
2016-01-03 15:37:24 UTC
Did you manage to get a non-generic, specific to work? I.e. do you have
Once we have examples for every cases, we can handle those in the code.
2016-01-03 23:03:00 UTC
The only example I can find in the spec:
“650” “+” “HS_DESC_CONTENT” SP HSAddress SP DescId SP HsDir CRLF Descriptor CRLF “.” CRLF “650” SP “OK” CRLF
but note that the clockskew command uses an escaped +. Understanding the spec is over my head and it would be better to consult TPO directly with these questions and the TAILS guys since they have a shared interest in this.
2016-01-10 15:09:42 UTC
I tried posting this message to the Tor developer’s list yesterday but it was rejected:
Control port filter and wildcards
At the moment we are implementing support for whitelisting wildcards in the controlport filter to support Onionshare and Ricochet.
Does Tor’s control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature.
If we whitelisted the wildcard add_onion *, we don’t want it to match some hypothetical feature add_onion * ; … I.e. not add_onion * ; GETINFO address.
(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands.)
2016-01-10 15:16:06 UTC
2016-01-10 15:27:46 UTC
Tor Control Protocol: multiple commands in a single line possible?
TLDR:
Does Tor's control protocol actually support something like ; ?
I.e. something like
signal newnym ; getinfo address
?
How many of there separators are there?
Can you provide examples please?
Background:
At the moment we are implementing support for whitelisting wildcards for control-port-filter-proxy-python [0] to support Onionshare and Ricochet. [1] [2] [3] [4]
Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature.
If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address.
(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands. Or as stopgap, reject these separators since no applications using Tor's control protocol are currently using those.)
[0] https://github.com/Whonix/control-port-filter-python
https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy
[1] https://phabricator.whonix.org/T446
[2] https://phabricator.whonix.org/T445
[3] https://www.whonix.org/wiki/Next#onionshare
[4] https://phabricator.whonix.org/T448
2016-01-10 17:01:34 UTC
2016-01-10 17:55:46 UTC
2016-01-13 14:33:14 UTC