Re: user flags in public temp space (was Re: chflags() [heads up])

[sirsyko () TEMP ISHIBOO COM (sirsyko () TEMP ISHIBOO COM)]

> 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.

The discoverer of this bug and I were theorizing for a while. From what we
could see, this is the only file in /tmp that is a default target of attack.
However for other multi-user systems, running such as X11 (screen and ssh
behave properly it seems), its conceivable that you could race the creation of
/tmp/.X11 which is usually sticky (meaning you couldnt use bitwrior's old
cookiemonster exploit). However, with a directory thats created by a normal
user, after /tmp is cleared but while the system is still starting up (crontab
entry?) this might leave X11 open to cookie grabbing (/tmp/.X11 would remain
on the fs even after many reboots and attempts at clearing /tmp, always owned by
the ordinary user). I wonder if X does as strong of a check on the path
permissions as say sendmail and ssh?

<ss>