[tor-dev] Control-port filtering: can it have a reasonable threat model?

[Nick Mathewson]

Hi!

As you may know, the Tor control port assumes that if you can
authenticate to it, you are completely trusted with respect to the Tor
instance you have authenticated to.  But there are a few programs and
tools that filter access to the Tor control port, in an attempt to
provide more restricted access.

When I've been asked to think about including such a feature in Tor in
the past, I've pointed out that while filtering commands is fairly
easy, defining a safe subset of the Tor control protocol is not.  The
problem is that many subsets of the control port protocol are
sufficient for a hostile application to deanonymize users in
surprising ways.

But I could be wrong!  Maybe there are subsets that are safer than others.

Let me try to illustrate. I'll be looking at a few filter sets for example.
=====
Filters from https://github.com/subgraph/roflcoptor/filters :

1. gnome-shell.json

This filter allows "SIGNAL NEWNYM", which can potentially be used to
deanonymize a user who is on a single site for a long time by causing
that user to rebuild new circuits with a given timing pattern.

2. onioncircuits.json

Allows "GETINFO circuit-status" and "GETINFO stream-status", which
expose to the application a complete list of where the user is
visiting and how they are getting there.

3. onionshare-gui.json

Allows "SETEVENTS HS_DESC", which is exposes to the application every
hidden service which the user is visiting.

4. ricochet.json

Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above.

5. tbb.json

Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see
"onioncircuits" above.

=====
Filters from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/tor-controlport-filter.d
:

1. onioncircuits.yml

See onioncircuits.json above; it allows the same GETINFO stuff.

2. onionshare.yml

As above, appears to allow HS_DESC events.  It allows "GETINFO
onions/current", which can expose a list of every onion service
locally hosted, even those not launched through onionshare.

3. tor-browser.yml

As "tbb.json" above.

4. tor-launcher.yml

Allows setconf of bridges, which allows the app to pick a hostile
bridge on purpose.  Similar issues with Socks*Proxy.  The app can also
use ReachableAddresses to restrict guards on the .

Allows SAVECONF, which lets the application make the above changes
permanent (for as long as the torrc file is persisted)
=====

So above, I see a few common patterns:
  * Many restrictive filters still let the application learn enough
about the user's behavior to deanonymize them.  If the threat model is
intended to resist a hostile application, then that application can't
be allowed to communicate with the outside world, even over Tor.

  * Many restrictive filters block SETCONF and SAVECONF.  These two
changes together should be enough to make sure that a hostile
application can only deanonymize _current_ traffic, not future Tor
traffic. Is that the threat model?  It's coherent, at least.

  * Some applications that care about their own onion services
inadvertantly find themselves informed about everyone else's onion
services.  I wonder if there's a way around that?

  * The NEWNYM-based side-channel above is a little scary.


And where do we go forward from here?

The filters above seem to have been created by granting the
applications only the commands that they actually need, and by
filtering all the other commands.  But if we'd like filters that
actually provide some security against hostile applications using the
control port, we'll need to take a different tactic: we'll need to
define the threat models that we're trying to work within, and see
what we can safely expose under those models.

Here are a few _possible_ models we could think about, but I'd like to
hear from app developers and filter authors and distributors more
about what they think:

 A. Completely trusted controller.  (What we have now)

 B. Controller is untrusted, but is blocked from exfiltrating information.
    B.1. Controller can't connect to the network at all.
    B.2. Controller can't connect to the network except over tor.

 C. Controller is trusted wrt all current private information, but
future private information must remain secure.

 D. Controller is trusted wrt a fraction of the requests that the
clients are handling. (For example, all requests going over a single
SOCKSPort, or all ADD_ONION requests that it makes itself.)

 E.  Your thoughts here....?




signing-off-before-this-turns-into-a-capabilities-based-system,
-- 
Nick