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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Sat Dec 17 23:52:38 UTC 2011

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

  * status:  closed => reopened
  * resolution:  implemented =>


 I'm reopening this because this change is causing lsof to become
 nonfunctional, and other utilities like netstat and ss to be missing
 information. This change is *not* what Ubuntu is doing to prevent ptrace
 except by child processes - it's far more disruptive to users and the
 development I do because it makes '/proc/<pid>/fd' only readable by root.

 According to rransom and ioerror this isn't necessarily a bad thing, but I
 want to be very certain that this is what we want going forward (with
 signoff by Nick and Roger) because this is highly disruptive to arm.
 Here's the backlog...

 12:37 < atagar> ioerror: Your ptrace change doesn't just mess with gdb but
 also changes the /proc permissions, partly messing with system utilities
 (netstat, lsof, etc) - is this really necessary?
 12:39 < rransom_> atagar: I thought it was completely useless (They could
 just crack root and attach a debugger anyway). (Until it broke arm's
 connection view.)
 12:40 < atagar> rransom_: Thanks, your trolling is charming. You can still
 get connections as root, and even non-root if you're fine with a few
 incorrect results.
 12:44 < Sebastian> atagar: afaict all we do is prctl(PR_SET_DUMPABLE, 0);
 12:44 < Sebastian> on linux
 12:45 < Sebastian> atagar: that seems to indicate that whatever happens
 with /proc is necessary for this too, not sure
 12:46 < atagar> gotcha, the thing that breaks direct proc reads (and
 probably is disrupting the pid/process name entry for netstat, ss and
 such) is the permissions on /proc/<pid>/fd
 12:46 < atagar> dr-x------ 2 root   root   0 2011-12-17 12:02 fd
 12:54 < atagar> hmm, the PRCTL man page makes it sound like this should
 only effect core dumps
 12:54 < Sebastian> debuggers use the core dump facility
 12:54 < Sebastian> (getting a core dump doesn't mean your process has
 necessarily crashed)
 12:56 < Sebastian> there's also a documentation patch
 12:57 < Sebastian> to explicitly mention that PTRACE_ATTACH is disabled
 13:20  * atagar goes back to writing the stem general auth function
 13:20 < atagar> Pathetically I've been meaning to write it for two weeks
 now but keep getting distracted by other things. Today victory *will* be
 mine. :P
 14:40 < ioerror> atagar: yes, well, the new ubuntu sets it for all
 14:40 < ioerror> atagar: so normal users can't dump your process that is
 already running (in the case of malware, it can't dump your ssh keys in
 memory and they're encrypted on disk, right?)
 14:40 < ioerror> so this does actually help users
 14:40 < ioerror> and yes, obviously if you can root the box, you win
 14:48 < atagar> ioerror: if you're taking about the change for Maverick
 then that's something different
 14:50 < atagar> The tor change is preventing lsof results, and dropping
 pid identifiers from others. I'm running natty and any builtin ptrace
 disabling isn't doing that.
 14:53 < Sebastian> atagar: can you explain how exactly it is different?
 14:54 < Sebastian> reading the wikipedia page doesn't directly tell me how
 it differs
 14:54 < ioerror> thta is exactly the same
 14:54 < ioerror> atagar: if you launch tor - can you attach to it?
 14:55 < ioerror> atagar: in any case, with the ubuntu kernel set to
 disallow dumping, does arm break also?
 14:56 < atagar> 'can you explain how exactly it is different?' -> I mean
 that it's differnt behaviorally. If natty is preventing ptracing (as the
 article suggests) then it's doing it in a way that doesn't break
 14:57 < bliss> you might be seeing problems with yama
 14:57 < bliss> try echo 0 > /proc/sys/kernel/yama/ptrace_scope
 14:57 < bliss> (not on a production machine, just if you're developing on
 that box)
 14:58 < ioerror> atagar: i don't buy that me setting PR_SET_DUMPABLE
 breaks all those tools alone
 14:58 < ioerror> atagar: can you show me documentation of that?
 14:58 < atagar> 'in any case, with the ubuntu kernel set to disallow
 dumping, does arm break also?' -> I don't have any reports of breakage,
 except via the tor change. The other report (from Stephan) looks to be a
 difference in proc formatting on debian.
 14:59 < atagar> ioerror: did you read my last message on the tor-talk@
 14:59 < atagar> if so then you should be able to easily repro
 14:59 < ioerror> atagar: i don't have arm on aan ubuntu box right now
 15:00 < atagar> you don't need arm, you need netstat/ss/lsof
 15:00 < bliss> PR_SET_DUMPABLE just prevents non-root process from
 ptracing the calling process
 15:00 < ioerror>  ps auxw|grep tor|wc -l
 15:00 < ioerror> 12
 15:00 < ioerror> io        2096  0.1  1.2  71700 26724 ?        S    Dec15
 2:28 /usr/sbin/tor
 15:00 < ioerror> so i have a tor running as me
 15:00 < bliss> Yama, which is on more recent ubuntus, prevents ptrace
 attaches to anything except child processes
 15:00 < ioerror> and yes, i agree:
 15:00 < ioerror>  lsof -ni|grep -i tor|wc -l
 15:00 < ioerror> 0
 15:01 < ioerror>  sudo lsof -ni|grep -i tor|wc -l
 15:01 < ioerror> [sudo] password for io:
 15:01 < ioerror> 11
 15:01 < ioerror> so lsof on ubuntu no longer shows the connections of my
 own tor
 15:01 < ioerror> ironically, ssh and other things do show up :)
 15:01 < ioerror> good to know which processes that i can dump when i'm
 15:01 < atagar> also try "netstat -np", you'll find that tor connections
 are missing the PID/process name identifier
 15:01 < ioerror> that's awesome
 15:02 < bliss> you shouldn't be able to dump those as malware either
 15:02 < ioerror> bliss: depends on the platform
 15:02 < bliss> not sure if it's ptrace behavior that's affecting the lsof
 output there
 15:02 < bliss> on ubuntu
 15:02 < bliss> (maverick or later)
 15:02 < ioerror> atagar:  netstat -tnp shows:
 15:02 < ioerror> tcp        0      0         ESTABLISHED -
 15:03 < ioerror> tcp        0      0         ESTABLISHED -
 15:03 < ioerror> tcp        0      0         ESTABLISHED -
 15:03 < atagar> bliss: the PR_SET_DUMPABLE option that he's setting is
 making /proc/<pid>/fd only readable by root, which is what's breaking lsof
 15:03 < atagar> ioerror: right, that "-" is the issue :)
 15:04 < bliss> atagar: you sure that changes permissions on /prrc/pid/fd?
 15:05 < Sebastian> bliss: yeah, some googling also reveals reports of that
 15:06 < bliss> ok, that's interesting, wasn't aware of that
 15:06 < ioerror> atagar: it is?
 15:06 < bliss> finding the kernel code now, should be easier
 15:07 < atagar> ioerror: dr-x------ 2 root   root   0 2011-12-17 12:02 fd
 15:07 < ioerror> atagar: i'm not sure what to tell you other than "damn,
 that is really annoying that this kernel hardening feature works so well."
 15:07 < ioerror> atagar: i think this means that tor must send that info
 to you via the control port
 15:07 < ioerror> atagar: and actually, i think that is good
 15:08 < ioerror> atagar: it means that a local user on a box can't tell
 what tor is doing for another user (!) unless they can pop root (!)
 15:08 < ioerror> atagar: is that actually waht you're telling me? If so, I
 can't believe that worked so well
 15:08 < ioerror> atagar: also, man, that really relaly needs to be well
 15:08 < ioerror> atagar: like, whoa bug in documentation :(
 15:09 < atagar> If you're trying to match the protection in ubuntu then
 this isn't getting parity. If your goal is to break lsof/netstat/etc then
 ok, I'll try to make arm take this into account and warn the user.
 15:10 < atagar> 'it means that a local user on a box can't tell what tor
 is doing for another user' -> Hm? It breaks if you're the same user too.
 15:11 < bliss> code is in fs/proc/base.c, if you're curious :-)
 15:12 < bliss> ownership of /proc/pid is changed to pid only if the task
 is dumpable
 15:14 < Sebastian> that's what happens during setuid?
 15:14 < bliss> no, during prctl with PR_SET_DUMPABLE
 15:14 < Sebastian> interesting
 15:15 < bliss> setuid has other behavior
 15:15 < bliss> ownership is rewritten during setuid, but /proc/pid/fd has
 a special handler so a process can always access its own fd directory
 after setuid
 15:19 < atagar> I'm not really clear from this backlog, are we trying to
 break those utilities or is this a bug? May I reopen 3313 with this
 backlog? nickm: you should probably be aware of this too :)
 15:22 < Sebastian> atagar: From what I gather from what ioerror and
 rransom_ said it was an unintended but not unwelcome side-effect
 15:33 < ioerror> atagar: my goal is to prevent dumping
 15:33 < ioerror> atagar: ubutnu has a kernel patch to try to do it system
 wide but tor runs on lots of systems and not just ubuntu
 15:34 < 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)
 15:34 < ioerror> I think this is not unwelcome for me but clearly, it is a
 pain in your ass :(
 15:34 < ioerror> it was not intentional to break lsof and sss
 15:34 < ioerror> and other tools
 15:37 < atagar> 'unless tor gives it to you or you are root' -> I agree
 with the added bit of "or if you're the same user as tor". We don't want
 to suggest root for controllers and tor isn't gonna be emulating every
 *nix utility.
 15:37 < atagar> armadev, nickm: Please confirm that this is what we want
 going forward, and then I'll try to take it into account for the future.
 I've relied on utils like lsof quite a bit so I want to be clear that
 they'll be routinely non-functional from now on since this impacts how I
 develop things.
 15:37 < atagar> (And just to be clear, this really bugs me. I hope this
 added protection over what Ubuntu does by default is important because it
 puts me in the awkward position of either dropping a major feature or
 suggesting that users routinely set "DisableDebuggerAttachment 0")
 15:38 < ioerror> atagar: i don't want to sugget root for controllers - i
 think tor should give you the info you want if you're authorized to have
 15:38 < ioerror> atagar: DisableDebuggerAttachment should not be set to 0;
 we should find a way to fix this for everyone
 15:38 < ioerror> i have to go now
 15:39 < atagar> Ok. We need to continue this discussion and get nickm and
 armadev's input so I'll move this back to trac.

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

More information about the tor-bugs mailing list