I've pushed a revised protocol change to branch safecookie of git.tpo/rransom/torspec.git, and a (messy, needs rebase, untested) implementation to branch safecookie-023 of git.tpo/rransom/tor.git.
Now, the client and server nonces are fed to the same HMAC invocation, so that the client can believe (modulo Merkle-Damgard and general iterative hash function ‘features’) that the server knows the cookie (rather than just HMAC(constant, cookie)).
Almost all controllers must drop almost all support for non-safe cookie authentication ASAP, because a compromised system-wide Tor process could drop a symlink to /home/rransom/.ed25519-secret-key in where it was supposed to put a cookie file.
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.
Robert Ransom
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? 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.
On 2012-03-16, Sebastian Hahn hahn.seb@web.de 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
-
Robert Ransom -
Sebastian Hahn