Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]

[long () KESTREL CC UKANS EDU (Jeff Long)]

If I understand your question correctly, the agent code only does a
chown on the directory where the socket will be stored.  Plus it only
does the chown if it had to create the directory (as root).

Hard links are also not a problem as bind() doesn't overwrite existing
files and you can't create a hard link (using ln) to a non-existing
file.

At least this is how it all appears to work on Digital/Compaq Tru64
Unix.

Jeff Long

Rush Carskadden wrote:
> I don't have Digital, nor do I fully understand the order that things
> get executed, but wouldn't it be possible to create a hardlink to a file
> that I (as a user) want access to in /tmp/ssh-<username> , allow it to
> get chown'd to me, then do as I please? It seems as though regardless of
> the protection from the symlink problem, my file still gets chown'd.
> Please forgive (educate) me if I am missing something.

<snip>
> Seeing the race problems with the previous two patches I thought I would
> take a shot at one.  It changes the effective uid/gid to the user
> logging in before doing the bind() (and then resets them after) which
> seems to take care of the problem.  It also chown's the
> /tmp/ssh-<username> directory before doing the bind in the case that it
> did not already exist so that the user owns it before performing the
> bind.  On Digital Unix 4.0D this seems to take care of the problem.  The
> bind() will fail if a symlink exists to a file that the user would
> normally not be able to write to (such as /etc/nologin).  The only other
> difference after logging in is that the socket will now be owned by the
> user instead of root but I can't think of a reason why this would be
> bad.
>
> If anyone sees problems in this patch please let me know.
>
> Jeff Long