Bug #9365

Evaluate consequences of full Tor circuit/stream state and restrict it as needed

Added by anonym 2015-05-09 15:23:22 . Updated 2019-08-30 20:17:48 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-05-09
Due date:
% Done:

10%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

Update: as discussed on Bug #10339#note-21, we need to focus on the non-Vidalia aspects first.

Note: The Tor Browser runs with a quite different set up than Tails, since the same user also runs the Tor process. For them, a browser compromise will always be worse than in Tails for that reason.

With “full Tor circuit/stream state” we mean having access to the following things via Tor control port:

  • SETEVENTS stream
  • GETINFO circuit-status
  • GETINFO stream-status
    I.e. what’s required by Torbutton for its per-tab circuit view.

First of all, a compromised application will know the end points it communicates with, so the state of its traffic’s Tor circuits isn’t very interesting to an attacker (and does this extend to all processes run by the same user?). Hence the main issue with access to the above commands is that a compromised application will learn everything done with Tor, including processes run under another user.

Also, for contrast, let’s quickly examine what can currently be done to learn stuff about Tor circuits without using the control port:

  • netstat will expose the list of guards (or bridges).
  • whatismyip.com (or similar) can be used for learning the exits of current circuits with some probability, but only when Tor reuses circuits. However, it cannot be done with Tor Browser’s domain isolation, or any SOCKSPorts with IsolateDestAddr, so this approach is useless in Tails.
  • Leveraging Vidalia via X “features” to learn something close to “full Tor circuit/stream state”? (Bug #9366)
  • More?

Subtasks

Related issues

Related to Tails - Bug #9366: Is user separation enough to hide Tor state from Vidalia? Resolved 2015-05-09
Related to Tails - Feature #9001: Onion Circuits should connect via the Tor control port filter Resolved 2015-03-03
Related to Tails - Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? Rejected 2015-10-06

History

#1 Updated by intrigeri 2015-05-10 16:40:07

  • related to Bug #9366: Is user separation enough to hide Tor state from Vidalia? added

#2 Updated by intrigeri 2015-05-10 16:41:57

  • Description updated

#3 Updated by anonym 2015-07-01 11:54:38

  • Target version changed from Tails_1.4.1 to Tails_1.5

#4 Updated by anonym 2015-08-03 11:01:05

  • Target version changed from Tails_1.5 to Tails_1.6

#5 Updated by anonym 2015-09-07 13:12:27

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

anonym wrote:
> Also, for contrast, let’s quickly examine what can currently be done to learn stuff about Tor circuits without using the control port:

I think the key to reason about this issue is to do a comprehensive examination/comparison of this. To make it a bit more concrete and easy to reason about, let’s focus on looking what is exposed to the Tor Browser and user running it (amnesia).

> * netstat will expose the list of guards (or bridges).

Hence, without a way to limit this by making a system user only aware of its own connections (and not the tor process’), we must consider any application able to enumerate the guards/bridges used. It seems like such a limit should be possible to set, since connections are owned by PIDs, and PIDs by users. Any ideas? This seems worthwhile.

> * whatismyip.com (or similar) can be used for learning the exits of current circuits with some probability, but only when Tor reuses circuits. However, it cannot be done with Tor Browser’s domain isolation, or any SOCKSPorts with IsolateDestAddr, so this approach is useless in Tails.

This still seems valid to me. Well, obviously the exit can be learned for the circuit used to fetch whatismyip.com or similar, but that’s hardly interesting given the stream isolation options used forces a new circuit for that fetch.

Furthermore, nothing about the middle or exit nodes are available anywhere on the Tails system except in Tor’s internal state, so there shouldn’t be any way the learn them except: by using some exploit that gives the rights of the debian-tor user, or access to its memory (but this is obvious and not very interesting); it could also be done via Tor’s ControlPort. We limit access to it as tightly as possible using the tor-controlport-filter, so we should be good.

> * Leveraging Vidalia via X “features” to learn something close to “full Tor circuit/stream state”? (Bug #9366)

If this is a problem, then pretty much everything else considered in this discussion is irrelevant. Note that I have updated that ticket with a pretty mundane (but easy for users to detect) way to exploit it, which we need to consider.

> * More?

Let’s revisit an interesting question raised in the description:

> […] a compromised application will know the end points it communicates with […] [but] does this extend to all processes run by the same user?

I’d like a definitive answer there especially given that the Tor Browser is confined by AppArmor. I would like to assume it made other parts of the user’s memory off-limits. Otherwise a compromised Browser would know of all end-points communicated with by processes run under the same user. That’s pretty bad. What may be of some comfort is that if a Tails user is behind a NAT (which should be extremely common) it will not know the external IP address, so its not full deanonymization necessarily. That is unless there’s some other way to learn it than Tor’s ControlPort’s GETINFO address.

However, without the full ControlPort access, a compromised application should not have any insight in the Tor circuit/stream state of processes run by another user. By default: we contact tails.boum.org to check for upgrades and security notices, which isn’t interesting at all; we also do the time syncing, which makes it possible to learn the system Time, but the Tor Browser already knows this. I don’t think there’s anything else, so why this may sound nice, it’s not much in practice.

Now that the Tor Browser finally cannot access the LAN (Feature #7976) I don’t think there could be much more fundamental issues relating to this, barring esoteric side-channels that I do not have time (and knowledge, probably) to muster the academic creativity for. Hence it seems Tails’ current separation between Tor Browser and Tor process, particularly including the limits set on Tor ControlPort access for the amnesia user that runs the Tor Browser, may make the situation better than if we give the Tor Browser access to the full Tor circtui/stream state, but there are still some open questions which makes the “better” range from “none” to “a lot” to “give it to me!”. Let’s summarize it like this:

These things are definitely better if we do not grant the Tor Browser access to the full Tor circuit/stream state:

  • The Tor Browser cannot learn anything about the Tor circuit/stream state for processes run by other users than amnesia. (Not very interesting.)
  • The Tor Browser cannot learn anything about middle nodes used for any circuit, including its own and those used by processes run by the amnesia user. (Not very interesting in itself.)
  • The Tor Browser cannot learn anything about exit nodes used for any circuit, including its own and those used by processes run by the amnesia user (with the exception of whatismyip.com-like stuff, attacker controlled end-points). The key point is that it cannot learn the exit node used for some arbitrary connection. (Not very interesting in itself.)

For each positive answer to these questions, it’s better to not grant the Tor Browser access to the full Tor circuit/stream state:

  • Can we limit netstat (and whatever low-level facility it in turn uses) to only supply users with information about the connection they “own”? (Big impact: guard discovery. Note that we currently are affected by this issue.)
  • Does the Tor Browser AppArmor confinement (or other protection in place) prevent it from learning what end-points other processes run by amnesia think they are speaking to? (Big impact.)
  • Are the parts of Bug #9366 that we care about impossible or can they be ignored? (Ultimate impact, makes all other considerations irrelevant.)

So to me it seems like the current benefits we know of are pretty weak. We must resolve Bug #9366, and if the answer is “yes, it is impossible/can be ignored”, then the other two big impact questions should be tackled — any one of them would be a nice advantage to have, IMHO. If the answer is “no, Vidalia (or Tor Monitor) is a problem”, then we have a hard “security vs usability” consideration to make.

#6 Updated by anonym 2015-09-07 13:17:43

  • Assignee changed from anonym to jvoisin
  • QA Check set to Info Needed

Do you have any opinion? If not, or if you cannot look into this in the next couple of days, please just reassign it to me and unset the “QA Check” status.

#7 Updated by bertagaz 2015-09-12 08:52:47

Trying to answer what I feel able to do.

anonym wrote:
> anonym wrote:
> > Also, for contrast, let’s quickly examine what can currently be done to learn stuff about Tor circuits without using the control port:
>
> I think the key to reason about this issue is to do a comprehensive examination/comparison of this. To make it a bit more concrete and easy to reason about, let’s focus on looking what is exposed to the Tor Browser and user running it (amnesia).
>
> > * netstat will expose the list of guards (or bridges).
>
> Hence, without a way to limit this by making a system user only aware of its own connections (and not the tor process’), we must consider any application able to enumerate the guards/bridges used. It seems like such a limit should be possible to set, since connections are owned by PIDs, and PIDs by users. Any ideas? This seems worthwhile.

More on that later in my reply.

> > * whatismyip.com (or similar) can be used for learning the exits of current circuits with some probability, but only when Tor reuses circuits. However, it cannot be done with Tor Browser’s domain isolation, or any SOCKSPorts with IsolateDestAddr, so this approach is useless in Tails.
>
> This still seems valid to me. Well, obviously the exit can be learned for the circuit used to fetch whatismyip.com or similar, but that’s hardly interesting given the stream isolation options used forces a new circuit for that fetch.
>
> Furthermore, nothing about the middle or exit nodes are available anywhere on the Tails system except in Tor’s internal state, so there shouldn’t be any way the learn them except: by using some exploit that gives the rights of the debian-tor user, or access to its memory (but this is obvious and not very interesting); it could also be done via Tor’s ControlPort. We limit access to it as tightly as possible using the tor-controlport-filter, so we should be good.

Agree.

> > * Leveraging Vidalia via X “features” to learn something close to “full Tor circuit/stream state”? (Bug #9366)
>
> If this is a problem, then pretty much everything else considered in this discussion is irrelevant. Note that I have updated that ticket with a pretty mundane (but easy for users to detect) way to exploit it, which we need to consider.

This should be discussed in Bug #9366.

> Let’s revisit an interesting question raised in the description:
>
> > […] a compromised application will know the end points it communicates with […] [but] does this extend to all processes run by the same user?
>
> I’d like a definitive answer there especially given that the Tor Browser is confined by AppArmor. I would like to assume it made other parts of the user’s memory off-limits.

I don’t think you can assume that. Protecting from e.g buffer overflow is not an apparmor feature. But maybe I’m misunderstanding your assumption/question.

> Otherwise a compromised Browser would know of all end-points communicated with by processes run under the same user. That’s pretty bad. What may be of some comfort is that if a Tails user is behind a NAT (which should be extremely common) it will not know the external IP address, so its not full deanonymization necessarily. That is unless there’s some other way to learn it than Tor’s ControlPort’s GETINFO address.
>
> However, without the full ControlPort access, a compromised application should not have any insight in the Tor circuit/stream state of processes run by another user. By default: we contact tails.boum.org to check for upgrades and security notices, which isn’t interesting at all; we also do the time syncing, which makes it possible to learn the system Time, but the Tor Browser already knows this. I don’t think there’s anything else, so why this may sound nice, it’s not much in practice.

Agree.

> Now that the Tor Browser finally cannot access the LAN (Feature #7976) I don’t think there could be much more fundamental issues relating to this, barring esoteric side-channels that I do not have time (and knowledge, probably) to muster the academic creativity for. Hence it seems Tails’ current separation between Tor Browser and Tor process, particularly including the limits set on Tor ControlPort access for the amnesia user that runs the Tor Browser, may make the situation better than if we give the Tor Browser access to the full Tor circtui/stream state, but there are still some open questions which makes the “better” range from “none” to “a lot” to “give it to me!”. Let’s summarize it like this:
>
> These things are definitely better if we do not grant the Tor Browser access to the full Tor circuit/stream state:
>
> * The Tor Browser cannot learn anything about the Tor circuit/stream state for processes run by other users than amnesia. (Not very interesting.)
>
> * The Tor Browser cannot learn anything about middle nodes used for any circuit, including its own and those used by processes run by the amnesia user. (Not very interesting in itself.)
>
> * The Tor Browser cannot learn anything about exit nodes used for any circuit, including its own and those used by processes run by the amnesia user (with the exception of whatismyip.com-like stuff, attacker controlled end-points). The key point is that it cannot learn the exit node used for some arbitrary connection. (Not very interesting in itself.)

I believe they are good features.

> For each positive answer to these questions, it’s better to not grant the Tor Browser access to the full Tor circuit/stream state:
>
> * Can we limit netstat (and whatever low-level facility it in turn uses) to only supply users with information about the connection they “own”? (Big impact: guard discovery. Note that we currently are affected by this issue.)

The apparmor-profiles package ships a profile for netstat. I gave it a try, but the resulting test showed that it just prevents any user to see any connections, even its own. I’ve tried to modify it a bit, but couldn’t get it to give only the user’ connections. Only root can see the full connection list correctly, I think mostly because the files in /proc/$PID/net/ are owned by root. But maybe that’s better than nothing?

> * Does the Tor Browser AppArmor confinement (or other protection in place) prevent it from learning what end-points other processes run by amnesia think they are speaking to? (Big impact.)

Yes, I think it does. There are rules in the profile to limit the access to /proc, even from its own /proc/$PID/ directory. So you can’t just read connections informations from there. It doesn’t seem to be able to ptrace too.

> * Are the parts of Bug #9366 that we care about impossible or can they be ignored? (Ultimate impact, makes all other considerations irrelevant.)

I’ll reply later in this ticket.

> So to me it seems like the current benefits we know of are pretty weak. We must resolve Bug #9366, and if the answer is “yes, it is impossible/can be ignored”, then the other two big impact questions should be tackled — any one of them would be a nice advantage to have, IMHO. If the answer is “no, Vidalia (or Tor Monitor) is a problem”, then we have a hard “security vs usability” consideration to make.

Good plan! :)

#8 Updated by bertagaz 2015-09-23 01:31:45

  • Target version changed from Tails_1.6 to Tails_1.7

#9 Updated by anonym 2015-10-06 02:29:33

  • Target version changed from Tails_1.7 to Tails_1.8

bertagaz wrote:
> anonym wrote:
> > anonym wrote:
> > Let’s revisit an interesting question raised in the description:
> >
> > > […] a compromised application will know the end points it communicates with […] [but] does this extend to all processes run by the same user?
> >
> > I’d like a definitive answer there especially given that the Tor Browser is confined by AppArmor. I would like to assume it made other parts of the user’s memory off-limits.
>
> I don’t think you can assume that. Protecting from e.g buffer overflow is not an apparmor feature. But maybe I’m misunderstanding your assumption/question.

Right, that’s what I expected. But doesn’t the kernel have some user-defined memory protection?

Any way, given how Bug #9366 was resolved, I think we should focus on deciding Bug #10339. Only if we decide to remove all Vidalia-like tools is it relevant to consider this ticket any further.

#10 Updated by anonym 2015-10-06 02:29:46

  • blocked by Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? added

#11 Updated by sajolida 2015-11-08 02:38:16

  • blocks deleted (Bug #10339: Are the security risks introduced by Vidalia-like tools worth it?)

#12 Updated by sajolida 2015-11-08 02:38:26

  • blocks Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? added

#13 Updated by intrigeri 2015-12-20 03:47:24

  • Assignee changed from jvoisin to anonym
  • Target version changed from Tails_1.8 to Tails_2.2
  • QA Check deleted (Info Needed)

anonym wrote:
> Do you have any opinion? If not, or if you cannot look into this in the next couple of days, please just reassign it to me and unset the “QA Check” status.

Three months later, here we go.

#14 Updated by intrigeri 2016-01-03 20:52:35

  • blocked by deleted (Bug #10339: Are the security risks introduced by Vidalia-like tools worth it?)

#15 Updated by intrigeri 2016-01-03 20:52:42

  • related to Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? added

#16 Updated by intrigeri 2016-01-03 20:53:16

Given our conclusion on Bug #10339, in the current state of things, we assume that the amnesia user has full view of the Tor circuits and stream state.

#17 Updated by intrigeri 2016-02-21 10:54:04

  • related to Feature #9001: Onion Circuits should connect via the Tor control port filter added

#18 Updated by intrigeri 2016-02-21 12:04:24

  • related to deleted (Bug #10339: Are the security risks introduced by Vidalia-like tools worth it?)

#19 Updated by intrigeri 2016-02-21 12:04:35

  • blocks Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? added

#20 Updated by intrigeri 2016-02-21 12:08:26

  • Subject changed from What does full Tor circuit/stream state give an attacker? to Evaluate consequences of full Tor circuit/stream state and restrict it as needed
  • Description updated

#21 Updated by intrigeri 2016-02-21 12:33:00

  • Target version deleted (Tails_2.2)

anonym and I looked quickly into hiding the tor daemon’s connections from the amnesia user, and it doesn’t seem easy with the current design of Tails.

Something that would presumably work is to run the entire user session within a private pid+network namespace and a re-mounted /proc, ala:

sudo unshare --fork --pid --mount-proc --net bash -c 'cat /proc/$$/net/tcp'

It remains to be seen how this can be integrated into the login process, and whether it would break anything else (see e.g. Bug #8256 for why we disabled hidepid). Some PAM module, or logind support, perhaps?

#22 Updated by intrigeri 2016-02-21 12:33:17

  • Target version set to 2016

#23 Updated by Dr_Whax 2016-08-20 12:26:15

  • Assignee deleted (anonym)
  • Target version deleted (2016)

#24 Updated by intrigeri 2017-09-18 08:18:30

  • blocked by deleted (Bug #10339: Are the security risks introduced by Vidalia-like tools worth it?)

#25 Updated by intrigeri 2017-09-18 08:18:46

  • related to Bug #10339: Are the security risks introduced by Vidalia-like tools worth it? added

#26 Updated by intrigeri 2019-08-30 20:17:48

  • Status changed from In Progress to Confirmed