On Thu, 15 Nov 2001 16:27:12 EST, Ed Phillips writes:> >
> > The cookie used to be created under /tmp (and XAUTHORITY set so that X
> > applications would know where to find it), until someone decided that
> > NFS-sniffing ultimately wasn't worth defending against (since if
you
> > can't trust the directory where you're keeping your
cryptographic keys,
> > then .Xauthority is among the least of your problems).
>
> Well, I bet people would care if their private keys (auth forwarding)
> where getting stored in $HOME (NFS mounted)... ;-)
Ed, I deliberately removed openssh-dev from the recipients list on my
reply to you, because we're discussing issues that I'm sure have been
rehashed several times on this list, which is already noisier than it
needs to be. It was poor form for you to quote my response to you (in
an incomplete context) back to the list.
If the NFS traffic for $HOME can be sniffed, it can probably be spoofed,
and an attacker can simply write his own keys into
$HOME/.ssh/authorized_keys, $HOME/.shosts, or a similar sensitive
location, or to steal the (_hopefully_ password-protected) private key
file and attack the passphrase with brute force. It was not
unreasonable for OpenSSH to make the simplifying assumption that
$HOME/.ssh can be trusted.
> Actually, I'd guess that if you replaced the "cookies" file
with a
> symbolic link to any file on the system, you could remove that file
> (depending how many checks are being done). This can be avoided, right?
Why are you speculating about things you can easily test? It's not an
issue.
unlink("/tmp/ssh-XXXXX/cookies") was a problem when /tmp/ssh-XXXXX was
a
symlink; if "/tmp/ssh-XXXXX/cookies" is a symlink, only the symlink
gets
removed by the unlink(). This is why only files named "cookies" were
at
risk from that bug.
> Why is the solution moving the file somewhere else? Doesn't sshd still
> need to be careful about what it's removing as uid 0 (i.e., don't
remove
> the cookies file if it's a symbolic link, has the wrong inode number,
has
> the wrong contents, etc., etc.)?
When the file was located under /tmp, sshd had to do a fair amount of
work--creating the directory to contain it (safely!), with a unique
filename, and cleaning up after itself.
The fix was to let xauth use its default value, in the user's home
directory; the permissions there are more appropriate, and no
additional housekeeping is necessary.
For what it's worth, when I suggested the possibility of setting
XAUTHORITY to $HOME/.ssh/Xauthority, I was not suggesting introducing
anything like the previous supporting code (creating the directory or
trying to clean up the cookie file when the session ends); at most, I
was suggesting setting the value of the environment variable, and
perhaps using existing code to create $HOME/.ssh appropriately if it
didn't already exist.
> Okay... now I'm following you. I think /tmp is a good place for the
> cookies... much better than $HOME... but that depends on avoiding the
> problems in sshd.
FWIW, I disagree with Ed about /tmp being a good place for the cookies,
and agree with the decision to simplify the code.
--
Dan Astoorian People shouldn't think that it's better to
have
Sysadmin, CSLab loved and lost than never loved at all. It's
djast at cs.toronto.edu not, it's better to have loved and won. All
www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican