Bug #9366

Is user separation enough to hide Tor state from Vidalia?

Added by anonym 2015-05-09 15:26:28 . Updated 2016-07-21 12:48:56 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_1.7
Start date:
2015-05-09
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

While the primary reason for Vidalia running as a separate user is that it needs full access to the control port, which leak all Tor circuit state (Bug #9365) but also more dangerous stuff like the Tor process idea of the external IP address. However, since Vidalia is an X application, perhaps some X protocol magic can be used by a compromised application (under the amnesia user) to interact with Vidalia (and hence its full access to the control port) via some X protocol magic?

Subtasks

Related issues

Related to Tails - Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed Confirmed 2015-05-09
Related to Tails - Feature #7072: Research potential for deanonymization by a compromised "amnesia" user Confirmed 2018-06-04
Related to Tails - Feature #9001: Onion Circuits should connect via the Tor control port filter Resolved 2015-03-03

History

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

  • related to Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#2 Updated by intrigeri 2015-05-14 10:20:07

  • related to Feature #7072: Research potential for deanonymization by a compromised "amnesia" user added

#3 Updated by intrigeri 2015-05-25 09:51:37

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

#4 Updated by anonym 2015-07-01 11:54:39

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

#5 Updated by anonym 2015-08-03 11:01:18

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

#6 Updated by anonym 2015-09-07 12:11:41

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

Without invoking any “X protocol magic”, it’s pretty obvious (and indeed it was raised during the meeting that resulted in this ticket) that something like the Tails automated test suite can be implemented by an attacker, and can exploit Vidalia like this. E.g. xdotool or raw Xorg calls to click around, some image detection bits to guide the clicking, and OCR to collect the circuit/stream data. However, that is quite visible to the user. How problematic is that? Will users think it’s just Tails bugging out, or will they do an emergency shutdown and flee the country? If we decide it’s bad enough, then we don’t even have to do a deeper investigation about “X protocol magic”.

Also, what about when a user leaves the computer unattended even just for a short while (which seems to happen since users really want a screen locker)? Given how X works, it’s pretty simple to detect when a session seems inactive, and this can be done and most likely go undetected. OTOH an inactive session may not contain as juicy information. However, the guards and long-lived still running connections would still leak the full stream/circuit state. How bad is this?

BTW, a clarification: with “X protocol magic” we mean: is there’s a way to make the above part invisible so that a user may not detect it even if s/he is present? E.g. by opening Vidalia in a virtual frame buffer (or an unused GNOME workspace?) and interacting with it there without interfering with the user.

#7 Updated by anonym 2015-09-07 13:17:45

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

#8 Updated by jvoisin 2015-09-09 13:58:44

About the whole X related thing, I think this is a bit overkill. Either we switch to wayland (a big pile of unaudited/deeply-tested code), or we hack something with X that is trivially bypassable.

As long as we ship (vanilla) vidalia and make it accessible to the amnesia user, it will be moderately trivial to write a piece of code to get the real IP of the user. Everything else than not shipping it will be either painful (what about patching vidalia so it doesn’t leak the IP/localization?), or (almost) useless, in my opinion.

#9 Updated by intrigeri 2015-09-15 02:50:27

  • Assignee changed from jvoisin to anonym
  • QA Check deleted (Info Needed)

#10 Updated by anonym 2015-09-16 13:22:51

jvoisin wrote:
> About the whole X related thing, I think this is a bit overkill. Either we switch to wayland (a big pile of unaudited/deeply-tested code), or we hack something with X that is trivially bypassable.

ACK.

> As long as we ship (vanilla) vidalia and make it accessible to the amnesia user, it will be moderately trivial to write a piece of code to get the real IP of the user. Everything else than not shipping it will be either painful (what about patching vidalia so it doesn’t leak the IP/localization?), or (almost) useless, in my opinion.

I guess we have to think a bit about our threat model here. It seem like a good idea to tie in something like our tor-controlport-filter between Tor’s ControlPort and Vidalia that prevents GETINFO address. Still, that only helps when “protected” by a NAT, not when someone has a public IP address assigned to a network interface.

#11 Updated by anonym 2015-09-22 15:03:13

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

#12 Updated by anonym 2015-10-06 02:23:36

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 10 to 100

My answer to this ticket is: no, user separation is not enough. Vidalia/Tor Monitor is inherently problematic in the current state of X in Tails.

Let the battle between security nerds and UX people begin: Bug #10339

#13 Updated by intrigeri 2016-07-21 12:48:56

  • Affected tool deleted (Vidalia)