Page MenuHomePhabricator

research control port filter proxy whiltelist wildcard security implications
Closed, ResolvedPublic

Description

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

Details

Impact
Normal

Event Timeline

Patrick created this task.Dec 5 2015, 2:18 PM
Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick set Impact to Normal.
Patrick added subscribers: HulaHoop, WhonixQubes, Patrick.

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.

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

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.

HulaHoop (HulaHoop):

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.

Yes.

(At time of writing, none of the tickets does argue about allowing
'add_onion *' by default to make onionshare etc. work out of the box.)

A related point is, if adding a Tor hidden service from a compromised
Whonix-Workstation (add_onion) raises more risk than a compromised
Whonix-Workstation without add_onion capability.

HulaHoop added a comment.EditedDec 31 2015, 7:29 PM

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.

Patrick updated the task description. (Show Details)Jan 2 2016, 3:43 PM

Can you please post examples of multi lined commands?

The only generic example I can find:

Command = Keyword OptArguments CRLF / "+" Keyword OptArguments CRLF CmdData

Did you manage to get a non-generic, specific to work? I.e. do you have
an actually working example?

Once we have examples for every cases, we can handle those in the code.

HulaHoop added a comment.EditedJan 4 2016, 12:02 AM

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.

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.)

Rejected? Not signed up for the list or rejected by a human list manager? I'll work on an improved version of the draft.

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

Roger said per mail, 'there isn't any ";" support in the control protocol.'

Patrick closed this task as Resolved.Jan 13 2016, 3:33 PM
Patrick claimed this task.

No one else on the mailing list either claimed it supports this.