Project

General

Profile

Bug #9366

Is user separation enough to hide Tor state from Vidalia?

Added by anonym over 4 years ago. Updated over 3 years ago.

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

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

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 (#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?


Related issues

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

History

#1 Updated by intrigeri over 4 years ago

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

#2 Updated by intrigeri over 4 years ago

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

#3 Updated by intrigeri over 4 years ago

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

#4 Updated by anonym over 4 years ago

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

#5 Updated by anonym about 4 years ago

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

#6 Updated by anonym about 4 years ago

  • 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 about 4 years ago

  • 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 about 4 years ago

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 about 4 years ago

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

#10 Updated by anonym about 4 years ago

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 about 4 years ago

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

#12 Updated by anonym about 4 years ago

  • 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: #10339

#13 Updated by intrigeri over 3 years ago

  • Affected tool deleted (Vidalia)

Also available in: Atom PDF