From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 Prior to openssh-2.9p2, openssh never added the MIT-MAGIC-COOKIE-1 credentials for the forwarded X11 connection to the user's real Xauthority file, but instead used mktemp() to create a directory in /tmp, created a new Xauthority file (named "cookies") in the subdirectory, added its credentials to the new Xauthority file, and then propagated the XAUTHORITY environment variable. Unfortunately, when the session ended, xauthfile_clean_proc() didn't bother to temporarily switch to the user's uid before removing the cookies file its containing directory, thereby creating a race condition which could allow an attacker to remove any file on the filesystem named "cookies". Instead of just fixing xauthfile_clean_proc, the openssh developers ripping out all the code that relocated the .Xauthority file. (This is in spite of the fact that forwarded credentials continue to be located in /tmp, the same way that X11 cookies used to be located.) Thus, starting with 2.9p2, it is impossible to securely relocate the Xauthority file that openssh uses. ($HOME/.ssh/environment can set XAUTHORITY to a static location, but cannot call mktemp() to create a secure location.) For people whose home directories are not local (e.g. non-secure NFS), this may be a security risk. The following patch reverts the 2.9p2 changes, and fixes xauthfile_clean_proc() so that it temporarily switches to the user's uid before removing the agent socket and its containing directory. The OpenSSH developers will not apply this patch. When people protested the change on the openssh-unix-dev mailing list, the OpenSSH developers argued that if one's home directory is located on a remote machine, and the fileserver traffic can be snooped, then there's no use in protecting the cookie protecting a forwarded X11 session, because it is simply one of many important things that can be snooped. While I respect the OpenSSH developers' point, I disagree with it; I believe that is is worthwhile to protect the X11 cookies from potential disclosure, even if the contents of other files in one's home directory can be disclosed. I have audited this patch multiple times. I believe it to be secure, and I use it myself. But nonetheless, I suggest you do the same before using it. :p If you add this patch as Patch10 to the recent openssh-3.1p1-2.src.rpm errata, it will apply cleanly.
Created attachment 48565 [details] patch to revert OpenSSH's Xauthority file behavior
>For people whose home directories are not local (e.g. non-secure NFS), >this may be a security risk. No matter how many times I read that one sentence, I still get a chuckle out of it. ;o) In lieu of more specific example showing this to be a serious security threat, I believe I would agree with the openssh developers on this one.
OpenSSH provides another way to do this that works with newer versions. 1. In ~/.ssh/environment put XAUTHORITY=/tmp/.Xauthority 2. Enable PermitUserEnvironment in /etc/ssh/sshd_config I dug this up because I needed to use an NCP share as my $HOME, but xauth's file locking will not work on NCP. So, the issue reported in this bug report does have other implications than just security, but my solution works for me.
Okay, upon looking closer at the original comment, the ~/.ssh/environment solution does not use mktemp(). I think this could be done with ~/.ssh/rc or /etc/ssh/sshrc though.
Does it still apply to the openssh-3.9p1 in the current Fedora Core? If yes, this must be accepted to upstream first anyway.
Yes, this comment still applies. ~/.ssh/rc cannot be used to do this, because there is no way for sshrc to propagate the value of $XAUTHORITY to the program/shell that sshd execs. If, however, sshd would read the *output* that sshrc generates and treat it as additional environment commands (a la ~/.ssh/environment), then relocating the Xauthority file would be possible. The OpenSSH developers might be willing to accept such a patch, because whether sshd pays attention to any output that sshrc produces could be controlled via the PermitUserEnvironment option, just as the processing of ~/.ssh/environment currently is. I will ask and see.
OK, please report it upstream and add the link here.
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=110780105230311&w=2 No responses as of yet.