[tor-bugs] #3076 [Tor Client]: Implement 'SocksPort auto' and 'ControlPort auto'

[Tor Bug Tracker & Wiki]

#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