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
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.
No responses as of yet.