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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Mon Dec 19 03:13:13 UTC 2011

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

Comment(by ioerror):

 Replying to [comment:19 atagar]:
 > Little update from what ioerror and I have been discussing on irc. We
 have a partial workaround that limits the impact on arm - since we still
 have netstat results I can filter on the uid of the tor owner rather than
 the pid. This has the obvious disadvantage that it may be overly inclusive
 if tor isn't run under a dedicated user, but should be fine for the deb
 use case.

 Right - so in essence we get all the security features we want, we look at
 /proc/net/tcp for a reasonable guess and on Debian systems or any systems
 with a dedicated uid, we're pretty much certain.

 > I'm not sure how this will work for BSD platforms because neither
 netstat nor proc contents are available there. That said, I'm not sure if
 this feature effects lsof/sockstat/procstat at all on that platform so it
 may not be an issue.

 Using these tools as an API is not stable. What if the OS had changed
 this? That is - what if the Ubuntu kernel change had caused this? As it
 stands, arm won't work on grsec enabled kernels that have similar
 restrictions as far as I can tell.

 > -Damian
 > PS. Sorry for flagging this as a blocker. I didn't realize that we
 reserved that status for critical security issues. At work it just means
 that it needs someone to look at it before final release.

 We're pretty far from a final release and it's good to highlight the

 The good news is that what we have lost by adding this feature is
 literally this and this alone:

 01:16 < atagar> if we're looking for the subset then we can simply look at
 the return values for the connection utils - that's all I care about :)
 01:17 < atagar> so that would just be the current ip/port on the local and
 foreign end
 01:17 < atagar> everything outside of that I discard
 01:17 < atagar> getting this from the control socket has the obvious
 advantage that we can get extra information that I currently need to infer
 01:18 < atagar> like which connections are exit/client and hence private
 01:18 < atagar> or which are directory/hidden service/client related
 01:19 < atagar> here's the proposal we came up with:
 01:20 < atagar> hm, forgot we had dropped connection info from that

 So - the main change is the connections that are ESTABLISHED or in a phase
 of connecting is that only information that is lost. I think that this is
 something that we could add to the heartbeat - arm could then get the
 information directly from Tor and it would be portable. We already have an
 internal state for those connections that includes important metadata
 anyway, right?

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

More information about the tor-bugs mailing list