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 okirat_private | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax okirat_private +------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:05:16 PDT