Re: Fix for ssh-1.2.27 symlink/bind problem

[sgifford () TIR COM (Scott Gifford)]

You're right, of course.  I had the semantics for rmdir() mixed up
with umount() momentarily.  I have fixed the comments in my copy of
the patch, but won't bother to distribute it unless something else
changes, or somebody is feeling really picky about their comments...

This doesn't affect the security of the patch, though; once we are
inside the directory, if somebody rmdir()s it and makes another
directory with the same name, that's not the directory we're in, and
we won't be tricked into overwriting anything as root (although we
will rmdir() the fake directory).  I tested this, and the bind()
simply fails, which is no big deal.  This is on Linux 2.2.12, and it
looks like BSD exhibits the same behavior.

------Scott.

Olaf Seibert <rhialto () polder ubc kun nl> 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.
>
> On the other hand, if you're in an rmdir()ed directory, a chdir ("..")
> or a rename("somename", "../somename") also don't work, and it looks
> like even creation of new files or sockets will fail too, so this could
> probably be used as a detection after the fact.
>
> (all this on NetBSD 1.3.3)
>
> -Olaf.
> --
> ___ Olaf 'Rhialto' Seibert - > ___ Olaf 'Rhialto' Seibert - rhialto () polder ubc.     -- If one tells the truth,
> \X/ .kun.nl          -- one is, sooner or later, to be found out. (Oscar Wilde)