On 2012-03-16, Sebastian Hahn 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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
