[11284] in bugtraq
Re: user flags in public temp space (was Re: chflags() [heads up])
daemon@ATHENA.MIT.EDU (sirsyko@TEMP.ISHIBOO.COM)
Fri Aug 6 06:03:48 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <19990805221227.1751.qmail@temp.ishiboo.com>
Date: Thu, 5 Aug 1999 18:12:27 -0400
Reply-To: sirsyko@TEMP.ISHIBOO.COM
From: sirsyko@TEMP.ISHIBOO.COM
X-To: strange@cultural.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.BSF.3.96.990804111716.22740A-100000@peabody> from Strange
at "Aug 4, 99 11:46:43 am"
> 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>
