Re: Linux and world-writable /tmp - UPDATE (fwd)

[okir () MONAD SWB DE (Olaf Kirch)]

On Sat, 11 Jul 1998 13:55:26 +0200, Michal Zalewski wrote:
> I fixed problems, now module can be safely installed and should work just
> fine. Version 0.3 is attached to this post, and also can be downloaded
> from:

There are some things I do not understand about this patch.

 1.     The code does not redirect /tmp access of processes running
        with a real, effective, or fs uid of root.

        So it doesn't buy you anything when it comes to /tmp attacks
        on setuid root programs.

        Other setuid/setgid apps are `protected' though.

 2.     The code does not keep normal users from messing around in
        the real /tmp directory. Use ///tmp, or chdir("/") and
        use "tmp", or unset both HOME and TMPDIR, or symlink your
        $HOME/tmp to /tmp, etc.

 3.     Some setuid programs do open temporary files in /tmp for
        a reason; they do not expect them to be created in /etc.
        They also do not expect that the user invoking the program
        can flip to a different directory underneath of it. An
        interesting attack (having redtmp loaded) would go like
        this:

        umask 0
        ln -s /var/spool/lpd $HOME/tmp

         *      run some hypothetical setgid daemon program,
                which creates /tmp/foo.1234.

                Because of redtmp, we now have /var/spool/lpd/foo.1234
                owned by you, group daemon.

         *      remove $HOME/tmp

         *      program now calls unlink(/tmp/foo.1234)
                Redtmp redirects to $HOME/tmp/foo.1234, which fails with
                ENOENT.

        Now you own a file in the LPD spool directory.
        Okay, this does not give you the same thrill as a root shell,
        but it demonstrates the fundamental weaknesses with /tmp
        redirection.

 *      It creates directories on the fly. Again, look at the hypothetical
        setgid daemon program. We invoke it as

        umask 0
        HOME=/var/spool/lpd theprogram ...

        When the program opens /tmp/foo.1234, redtmp redirects to
        /var/spool/lpd/tmp/foo.1234. The first attempt to open
        the file fails with ENOENT. The module now tries to be clever
        and calls mkdir(/var/spool/lpd/tmp, 0777).

        You now even have a directory in /var/spool/lpd, owned by you,
        group daemon, mode 0777.

        Having a subdirectory in a supposedly `safe' directory
        can be _very_ helpful in attacking some applications.


What I basically want to say is that set[ug]id programs that
don't stuff away their privileges first thing in main() are a bad
thing, and redtmp (or any type of /tmp redirection, e.g. through
plain TMPDIR) makes them worse.

I would much more prefer a kernel patch that goes bleep bleep bleep
whenever a program accesses a file in a mode 1777 directory when[*]

        current->euid < current->uid || current->egid < current->gid

or when the open flags do not contain O_EXCL.

That's not a real security measure, but it's a good diagnostic tool
in order to pin-point unsafe applications. Which is much more helpful
to Linux developers than work-arounds like /tmp redirections.


Olaf

Note:
 [*]    Admittedly a stupid heuristic, but most of the time you
        do assign your uids with values < 100 having some sort of
        privilege in the system, and higher values for `real' users.
--
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir () monad swb de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir () caldera de    +------------------------------------------------------