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

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

Hi Nick. Just a quick note that something I've wanted from time to
time is a 'make the control port read-only' option so only GETINFO,
GETCONF, events, etc would work. Yes, these could be used to
deanonymize a user, but it could provide assurance the controller
doesn't tamper with tor. This has been of interest to me since nyx
(aka arm) is primarily a read-only monitor and this could provide
users with an assurance that it's not doing anything to their tor
instance.

Besides that, 'makes the control port read-only' is a pretty straight
forward, simple to understand capability for a torrc option to have.

Cheers! -Damian

On Mon, Apr 3, 2017 at 11:41 AM, Nick Mathewson <nickm@xxxxxxxxxxxxxx> wrote:
> 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
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev