Adam Morrison wrote: > From the OpenBSD change logs: > revision 1.59 > date: 1999/07/30 18:27:47; author: deraadt; state: Exp; lines: +20 -1 > do not permit regular users to chflags/fchflags on chr or blk devices -- > even if they happen to own them at the moment. Mike Frantzen (frantzenat_private), Kevin Kadow (kadokevat_private), and I were discussing the implications of the above revision to vfs_syscalls.c and realized it must be that root does not automatically override user-set flags -- root must first unset the flag. The vulnerability thus extends beyond the /dev directory to affect any shared directory where root-run programs or functions rely on the assumption that root can override any permissions a user sets on a file. This assumption is, alas, untrue in the case of user-set flags, e.g. uchg -- root must unset the flag before even root will be allowed to modify or remove the file. This inability to remove a user-owned file, say with 'rm -f', leads to problems other than a user being able to lock up all the ptys or seize misc. devices in order to play various easily-imagined tricks. Mike F. immediately seized on the assumption of many OSes that they can or will have cleared /tmp (and other temp dirs) while in single-user mode during the boot sequence. Thus, where there was no /tmp race before, there is now a /tmp race that the user will surely win for all non-volatile /tmp filesystems. As proof of concept, on an OpenBSD 2.5 system, we set a file in /tmp "_motd" containing some text designed to frighten your typical sysadmin and rebooted. /etc/rc contains something like the following lines on many BSD4.4-lite-derived systems: T=/tmp/_motd rm -f $T sysctl -n kern.version | sed 1q > $T echo "" >> $T sed '1,/^$/d' < /etc/motd >> $T cmp -s $T /etc/motd || cp $T /etc/motd rm -f $T The result of /tmp/_motd being present and immutable at boot-time should be obvious and would probably send a number of sysadmins to their CDs for a neat reinstall. Other than the psychological impact, this particular 'exploit' is fairly innocuous. Interestingly, in OpenBSD2.5, FreeBSD3.2, and BSDI3.2, motd appears to be the only file affected in the various rc scripts. On many systems, however, admins will have added programs that will rely on /tmp being clear[able] before a user could possibly run a function (through cron, at, logging in, etc.) and the results will be more than cosmetic. And of course, the immutability will exacerbate other /tmp races in which the code's author relies on a quick unlink() before grabbing the (predictable) filename. Possible long-term fixes we've theo-rized: a) Root should not use /tmp. Root is root and, as the proverbial 800-pound gorilla, can make temporary files wherever it pleases. FreeBSD, for example, seems to be doing a lot in /var/run, which is root-owned, and not world-writable. At least root should use subdirectories of /tmp and test to see if it can mkdir(1) them before use (see OpenBSD2.5's /etc/security, for example). b) In rm(1), make the -f option clear user flags when rm -f is called by root (not a bad workaround). c) Make root automatically override user-set flags (possibly will create other complications for user-land programs relying on root passing over such files). This would be akin to Solaris 2.51 and 2.6's ACLs. d) Modify vfs_syscalls.c to disallow user-set flags on files in directories the user does not own. Our guess is that all 4.4-lite derived BSDs that have not explicitly disallowed regular users to chflags/fchflags on character or block devices will be vulnerable. I happen to think that a combination of c and d would be best, but then, I am often an admin.... -M
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:56 PDT