[tor-bugs] #3313 [Tor Client]: Security enhancement against malware for Tor

[Tor Bug Tracker & Wiki]

#3313: Security enhancement against malware for Tor
----------------------------+-----------------------------------------------
    Reporter:  ioerror      |       Owner:  ioerror         
        Type:  enhancement  |      Status:  reopened        
    Priority:  major        |   Milestone:  Tor: unspecified
   Component:  Tor Client   |     Version:                  
  Resolution:               |    Keywords:                  
      Parent:               |      Points:                  
Actualpoints:               |  
----------------------------+-----------------------------------------------
Changes (by ioerror):

  * priority:  blocker => major


Comment:

 Replying to [comment:17 atagar]:
 > My two cents on this, btw, is that this is a major bug with this feature
 and DisableDebuggerAttachment should be disabled by default until it's
 fixed (probably by asking Ubuntu how their ptrace protections work). The
 arguments for breaking lsof and others on purpose has been...
 >
 > "< ioerror> atagar: my thought is that you should not be able to get
 that info unless tor gives it to you or you are root (which can sniff the
 network anyway)"
 >
 > Which I disagree with for a couple reasons...
 >
 > - Realistically we will not be investing the time to re-implement
 connection utilities. I made a proposal for getting this information from
 the control socket years back. It's collecting dust because I'm the only
 tor dev that cares about it, and C coding isn't the sort of thing I do for
 fun after a day of work. ;)
 >

 ssh-agent does this exact protection - it is assumed that the stuff in
 memory is more sensitive than the stuff on disk. This is the same case for
 Tor - the circuits I just built are sensitive and should be forward secret
 as much as is possible.

 > In essence by saying "unless tor gives it to you" you're saying that
 controllers should never have this information which I strongly disagree
 with. If people have an issue with how I'm scrubbing the data then please
 file a ticket against arm. Otherwise, relay operators have a right to have
 some idea of the activity going on with their own systems.
 >

 I think that it is reasonable for Tor to send it to controllers at the
 level it feels is safe to reveal. I think it's weird to suggest that this
 is a right and furthermore it is a bit odd to suggest that my patch
 violates that right... You can still get a lot of that information and I
 think a good fix would be to extend what Tor sends to arm.

 > Also, this change does *not* prevent controllers from getting tor
 connection information, it only prevents controllers from differentiating
 tor connections from others that aren't associated with applications. In
 other words this change screws with arm, but not malware in this respect.
 >

 Malware can't connect to Tor *at all* unless it has the control password,
 right? If it can dump memory of Tor, it can get the password and of course
 all the previously built circuits still in memory, etc.

 I don't think this patch is perfect but I think it's not reasonable to
 suggest that it has no impact on malware running as the same user or as a
 different user that is not root on the same system. Can you demonstrate
 otherwise? Without restarting Tor?

 > - That leaves the "or you are root" and we do not want to start
 encouraging controllers to need root permissions. We already do this for
 writing to the Debian torrc which has been a pita (breaking SETCONF and
 leading to weeks of effort by Jake to make a setuid workaround). Most
 platform already restrict the connection information when your lack the
 permissions of the tor process, and this seems good enough for me.
 >

 This is a side effect of stopping someone from core dumping Tor as it is
 running unless it launches it. Another way to fix this might be to launch
 Tor from arm as a normal user?

 > I'm flagging this as a blocker since I really don't want to see this
 make it out of alpha without being addressed.

 This doesn't block a release; I agree that we should consider the impact.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3313#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online