[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3313 [Tor Client]: Security enhancement against malware for Tor
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs