> 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. 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>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:10 PDT