It's worth noting that controllers able to run SETCONF can ask the tor
process to execute arbitrary programs:
man torrc | grep exec
So if you want a controller to have any less privileges than the tor
daemon does, you need a control port filter for SETCONF at the very
least.
Without a control port filter, what is the threat model of the
ControlSocketsGroupWritable and CookieAuthFileGroupReadable options?
Maybe the torrc documentation for those options should recommend using
one?
On Mon, Apr 03, 2017 at 02:41:19PM -0400, Nick Mathewson 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev