[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 =>
Comment:
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
processes
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
(https://en.wikipedia.org/wiki/Ptrace#Support)
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
proc/lsof/netstat/etc.
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@
thread?
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
malware
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
though
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 127.0.0.1:9051
127.0.0.1:36248 ESTABLISHED -
15:03 < ioerror> tcp 0 0 127.0.0.1:9050
127.0.0.1:59626 ESTABLISHED -
15:03 < ioerror> tcp 0 0 127.0.0.1:9050
127.0.0.1:60560 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
documented
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
it
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