[7289] in bugtraq
Re: Linux and world-writable /tmp - UPDATE (fwd)
daemon@ATHENA.MIT.EDU (Olaf Kirch)
Thu Jul 16 16:54:53 1998
Date: Thu, 16 Jul 1998 11:44:12 +0200
Reply-To: Olaf Kirch <okir@MONAD.SWB.DE>
From: Olaf Kirch <okir@MONAD.SWB.DE>
X-To: Michal Zalewski <lcamtuf@BOSS.STASZIC.WAW.PL>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Sat, 11 Jul 1998 13:55:26 +0200."
<Pine.LNX.4.00.9807111355030.4215-101000@lcamtuf.waw.pdi.net>
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 +------------------------------------------------------
