On Thu, 30 Sep 1999 15:04:14 EDT, Eric Griffis writes: > This race condition was pointed out to me a little while before my message > made it to the list, and I am still puzzled as to how one would get the > timing right to perform such a maneuvre. Is there a way to somehow detect > that there's been an lstat performed without being superuser? It *might* be theoretically possible to detect the lstat(), if you could make /tmp/ssh-username point to a remote filesystem on a server that's under the user's control, but even if it's possible, it's probably not easy. A hacked ssh client/agent might also be able to have inside information about when it's about to send the request for agent forwarding. However, suppose the program merely guesses at the timing. Even if you lose the race, you can just keep retrying until you win the race; you only have to get it right once. In other words, if the odds of getting it right are one in a million, try it a few million times. > Also, I think the amount of processor time it takes to create a symbolic > link is multiple times larger than the amount of time between the return of > lstat and actual socket creation, All it takes is for the scheduler to decide to end sshd's time slice at an inconvenient time--and the context switches relating to the system calls are probably good candidates for that. > Okay, I see a few other messages about popen, permissions and such... At the > moment, I believe disabling remote agent services entirely is the only sure > way to remedy the whole issue, which will require password authentication. > And sshd needs to be run as root to perform authentication. I don't think > there's an easy way around that one. Disabling agent forwarding is probably overkill. (It would nevertheless have been nice if sshd had a way to disable agent forwarding from /etc/sshd_config, but that's neither here nor there.) Until we apply the kernel patch which Alan Cox is producing (has produced?) for Linux (the only vulnerable OS I personally have to deal with), I'm employing the following workaround: if someone uses this DoS on one of our systems, I'm going to go kick his ass. The system logs and the timestamp on the /etc/nologin file created by the denial of service makes it fairly straightforward to track down the idiot responsible. Jeff Long's patch is the sort of method I had in mind for fixing the problem properly. I'm not sure whether there are other credentials which the code should also be giving away--for instance, if root belongs to supplementary groups, then perhaps directories that are writable by those groups might still be attacked by the exploit. It would be worth testing whether this is the case. If so, perhaps an appropriate "initgroups(...)" would help? One could also include Eric Griffis's code to do the lstat() beforehand, in conjunction with Jeff's fix, if one wanted to. Adding the lstat() check is safe and effective, and there's no reason not to do it in addition to the other mechanism for fixing the flaw. And here's yet another option. I have *not* actually tried the following, but from a quick reading of the code, I *think* the problem could be eliminated by adding this quick hack to newchannels.c, anywhere after the #include's but before the definition of auth_input_request_forwarding(): #undef SSH_AGENT_SOCKET_DIR #define SSH_AGENT_SOCKET_DIR "/var/run/ssh-%.50s" This overrides the definition in ssh.h (for sshd, but not for ssh-agent), and *should* cause SSH agent sockets to be created under /var/run instead of /tmp when the agent forwarding is being done by sshd (but not when it's being done by ssh-agent). I'm assuming here, of course, that /var/run exists and is writable only by root; feel free to substitute a more appropriate directory name if you don't like this one. Try this fix at your own risk. People with more spare time than I have should feel free to test whether this fixes the problem, and report back to the list whether or not it does any good. This "undef/define" fix is *not* compatible with Jeff's patch; if you try to use both fixes, you'll definitely break agent forwarding. Eric's code change is compatible with both Jeff's and mine. Hope this helps somebody.... -- People shouldn't think that it's better to have Dan Astoorian loved and lost than never loved at all. It's Sysadmin, CS Lab not, it's better to have loved and won. All djastat_private the other options really suck. --Dan Redican
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:31 PDT