Re: [tor-dev] Proposal 193: Safe cookie authentication

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2012-03-16, Sebastian Hahn <hahn.seb@xxxxxx> wrote:
>
> On Feb 10, 2012, at 12:02 AM, Robert Ransom wrote:
>> The sole exception to ânon-safe cookie authentication must dieâ is
>> when a controller knows that it is connected to a server process with
>> equal or greater access to the same filesystem it has access to.  In
>> practice, this means âonly if you're completely sure that Tor is
>> running in the same user account as the controller, and you're
>> completely sure that you're connected to Torâ, and no controller is
>> sure of either of those.
>
> Why is it so hard to do this?

I am not aware of any sane way for a program to determine which user
ID is on the other end of a TCP socket, even over the loopback
interface.  (Scraping the output of netstat or sockstat or lsof is
insane.)

> Can't we tell controllers to do a
> check of permissions, and only if they can't be sure refuse to use the
> requested path by default unless a config whitelist or user prompt
> allows it? I think that's a lot easier to implement for controllers, and
> I just don't really see the huge threat here. If you have malicious
> system-wide software on your host, you lost anyway.

* Not every program which can receive connections on the loopback
interface should be allowed to read every 32-byte file which I can
access.  (Such programs might not have access to any part of my
filesystem.)

* If Tor were intended to have read access to every file in my user
account, the Debian package would configure it to keep running as root
(even after startup).

* If an attacker compromises the Tor process after it has dropped
privileges, Tor can fool a controller into opening the wrong file by
dropping a symlink in the whitelisted location for the system-wide
cookie file.  There is no good way to avoid following a symlink when
opening a file.  (O_NOFOLLOW isn't a good way -- it still follows
parent-directory symlinks, it may not be available on all OSes, and it
is not likely to be available in all programming languages.)  fstat
(to check ownership and permissions after opening a cookie file) is
difficult enough to use that someone will not use it, even if their
controller can correctly guess what ownership and permissions the
cookie file should have.

* A user who configures a controller to connect to a remote Tor
instance's control port knows that he/she/it is allowing attackers on
the LAN to control the Tor instance.  He/she/it is unlikely to know
that attackers on the LAN can also read 32-byte files from his/her/its
client system's disk.

* I will have very sensitive 32-byte files in my Unixoid VFS tree Real
Soon Now.  Perhaps other people will, too.

* A subtle complex flaky kludge which most controller implementors
will not realize is necessary is not a valid substitute for a simple
new cookie-based authentication protocol that avoids filesystem
permission-check hacks entirely.


Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev