On Mon, Jun 04, 2001 at 03:17:04PM -0700, sarnoldat_private wrote: > On Mon, Jun 04, 2001 at 11:19:37AM -0400, David F. Skoll wrote: > > I could not duplicate this with OpenSSH 2.9p1-1 on Red Hat 6.2 > The problem code is invoked in the X forwarding of ssh. If you try > again, this time passing -X as a command line argument to the ssh > client, you may find different results. Depending upon the user's > combination of ssh_config and the server's sshd_config, this may or > may not be (quickly) exploitable on your system. [1] Running ssh -X > will create the /tmp/ssh-XXXXXXXX directory that is needed for the > exploit. The sshd documentation says that sshd wil not invoke 'xauth' if it finds and can execute either $HOME/.ssh/rc or /etc/ssh/sshrc. And you can get sshd to more safely write an xauthority cookie file using /etc/ssh/sshrc. But it still creates /tmp/ssh-XXXXXXXX/cookies -- in this case, making an empty file. Not only that, but sshd resets the XAUTHORITY value to point to this empty cookie, crippling the work done by /etc/ssh/sshrc. And then when the user logs out, sshd wipes out the empty, useless /tmp/ssh-XXXXXXXX/cookies. As for the patches that are more careful when creating /tmp/ssh-XXXXXXXX/cookies -- isn't there still an assumption that /tmp/ssh-XXXXXXXX/cookies won't be removed before the ssh session ends? Many system use tools like 'tmpwatch' to prune unused files while the system is running (instead of depending on things like tmpfs cleaning /tmp at reboot time). On those systems, if someone logs in with X forwarding enabled, but never runs any apps that need to read $XAUTHORITY, and stays on log enough that 'tmpwatch' removes the whole /tmp/ssh-XXXXXXXX directory, then don't you have another attack vector -- regardless of how careful you were when creating the cookies file & its parent directory? It seems to me this whole xauthority business may be adding complexity for no good reason. Since the DISPLAY name changes, and an Xauthority file can hold multiple X cookie credentials, is there any good reason why OpenSSH need to make, and then, wipe out, a special xauthority file? why it can't just add credentials to the default xauthority file? Wouldn't that be simpler and, almost by definition, more secure? If you really want to be polite/clean, you can use the xauth "remove" command to purge the cookie from ~/.Xauthority -Peter -- Cheap X "run as" hack available at http://www.tux.org/~peterw/
This archive was generated by hypermail 2b30 : Tue Jun 05 2001 - 17:49:56 PDT