Re: Fix for ssh-1.2.27 symlink/bind problem

[djast () CS TORONTO EDU (Dan Astoorian)]

On Mon, 04 Oct 1999 06:58:42 EDT, Olaf Seibert writes:
> On Sat, 2 Oct 1999, Scott Gifford wrote:
>
> > +   /* OK, now we know we're in the directory we created.  Nobody can
> > +    * rmdir() this because we are in it.  Nobody besides root can have
> > +    * made a symlink in here, because they wouldn't have permission.
> > +    * Lookin' good...
> > +   **/
>
> Actually, a directory *can* be rmdir()ed when it some process' current
> directory. You can try that with a couple of shells for instance. But
> once the directory is not empty, it cannot be rmdir()ed anymore. Perhaps
> you can use that fact to your advantage.

I noticed that questionable comment too.  I don't believe it's a
problem; the comment is merely imprecise.

If the directory is rmdir()'d, the bind() will just fail (you generally
can't create files or other objects in a directory that's been
rmdir()'d, for largely the same reasons you can't rmdir() a directory
that contains files).

However, the important point is that even if someone does
    rmdir /tmp/ssh-${username}/tempbinddir-${time}-${pid}
    mkdir /tmp/ssh-${username}/tempbinddir-${time}-${pid}

after sshd does the chdir(), in order to try to replace the directory
with one in which symlink mischief is possible, the newly-created
directory is still not the current working directory of the sshd
process.  That, in conjunction with the other checks the patch does,
such as verifying the ownership, permissions, device and inode numbers,
should be sufficient to ensure that the user hasn't tampered with the
directory.

If the rmdir/mkdir above were done *before* the chdir() call, this would
be detected by the ownership checks that the patch performs on "." after
the chdir().

If sshd were to use the full pathname of the directory (or a path that
passed through "..") instead of a simple relative pathname when doing
its checks or calling bind(), that would also be a problem; as far as I
can tell, the patch is handling it correctly.

--                          People shouldn't think that it's better to have
Dan Astoorian               loved and lost than never loved at all.  It's
Sysadmin, CS Lab            not, it's better to have loved and won.  All
djast () cs toronto edu        the other options really suck.    --Dan Redican