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 (frantzen@expert.cc.purdue.edu), Kevin Kadow
(kadokev@msg.net), 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