[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3076 [Tor Client]: Implement 'SocksPort auto' and 'ControlPort auto'
#3076: Implement 'SocksPort auto' and 'ControlPort auto'
-------------------------+--------------------------------------------------
Reporter: mikeperry | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version:
Keywords: | Parent: #2264
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by rransom):
Replying to [comment:15 nickm]:
> I think it is a problem. Two attacks here:
> 1) If the attacker can write to the file: The attacker overwrites the
listening port number before the controller reads the file. Now the
controller connects to the attacker instead. The attacker learns the
required AUTHENTICATE command, and now takes control of the Tor process.
On an NTFS-based Windows installation, only (a) the âLOCALSYSTEMâ account
(almost equivalent to Unixoid ârootâ), (b) the Tor user, and (c) an
administrative user who has previously asked Windows to give him/her/it
access to the Tor user's directories can read from or write to Tor files
within the Tor user's directories. (If the user is running TBB from a
FAT-formatted USB storage device, my understanding is that all users can
read and write in the TBB directory.)
Any attacker who can write to the control-port file either runs as the Tor
user or can write to the Tor executables. (The only attacker which could
run as the user running Tor, but not have write access to Tor itself, is a
piece of malware running in the Tor user's account on a computer on which
an installable Tor bundle was previously installed.) Given that, this
race-condition attack is one of the most difficult attacks available (to
implement ''and'' to use).
> 2) If the attacker can only read from the file: The attacker reads the
listening port number, then either kills Tor, provokes it to crash, or
somehow gets into a situation where the file is still there but Tor is not
still listening on that port. Now the attacker binds to that port, and
the controller to connect to it. The attacker learns the required
AUTHENTICATE command, and takes control of the Tor process when it
eventually restarts (assuming password authentication).
Vidalia notices when Tor exits, even if it hasn't established a control
port connection yet. Vidalia does not automatically restart Tor. The
only remaining potential issue to fix here is ensuring that Vidalia uses a
''different'' random password every time it starts Tor.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3076#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs