[2110] in bugtraq
Re: BUGTRAQ ALERT: Solaris 2.x vulnerability
daemon@ATHENA.MIT.EDU (Scott Chasin)
Wed Aug 16 11:25:16 1995
Date: Wed, 16 Aug 1995 09:11:05 MDT
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Scott Chasin <chasin@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199508161350.JAA16741@netspace.org> from "L-Soft list server at
NETSPACE.ORG" at Aug 16, 95 09:50:08 am
> ???? I'm on 2.4 HW 3/95 (plus a bunch of patches of course) and can't
> find this hole. I'm looking to see if we still have a 2.3 machine
> around.
Remember - The rc scripts responsible for chmoding /tmp with the
sticky bit is really broken.
If you look in /etc/rc2.d at S05RMTMPFILES you can see that the following
is obsolete for mounted /tmp filesystems:
--
# Traditional SunOS 4.x behavior has been to not remove directories in
# the /tmp directory; only simple files were removed. This lead to an
# inconsistancy when the tmpfs file system was used (which isn't persistant
# across boots. The following adopts the traditional System V behavior
# of removing everything in /tmp.
# clean up /tmp
# if /tmp or any of its subdirectories are mount points do not remove /tmp
M=`/sbin/mount | /usr/bin/egrep '^/tmp(/| )' | /usr/bin/wc -l`
if [ $M -eq 0 ]
then
# just remove files under directory if symbolic link
if [ -h /tmp ]
then
/usr/bin/rm -rf /tmp/*
else
/usr/bin/rm -rf /tmp
/usr/bin/mkdir /tmp
/usr/bin/chmod 1777 /tmp
/usr/bin/chgrp sys /tmp
/usr/bin/chown sys /tmp
fi
--
The above basically doesn't adhere to mounted /tmp filesystems. So upon
boot your /tmp (if mounted in some fashion) does not get the sticky-bit.
> > DESCRIPTION:
> > A race condition exists in /usr/bin/ps when ps opens a temporary
> > file when executed. After opening the file, /usr/bin/ps chown's the
> > temporary file to root and the renames it to /tmp/ps_data.
>
> Well, I can't seem to find the temp files, even while running the exploit.
> (With a while (1) ls -l ps.* |& grep -v "No match" running.)
They are there. Trust me. If still in doubt, try the following:
/bin/rm /tmp/ps_data; /bin/truss /bin/ps -eaf >& /tmp/truss.out
And then search for the chown() call in /tmp/truss.out.
> > WORKAROUND:
> > chmod +t /tmp
>
> If this is the truth. That means all of us *not* running with tmpfs will
> be affected. There is a bug in the code that the sticky bit works
> correctly on tmpfs but not on ufs.
Check the above /etc/rc2.d TMP script for why.
> > unlink ("/tmp/ps_data");
>
> Uhh. On my system this won't work since /tmp/ps_data is 664. Or is this
> a matter of trying to catch the program twice?
If the mode on /tmp doesn't have the sticky-bit set, you can remove ps_data.
> Mostly I wanted to point out the bugs in ufs /tmp with sticky bit on.
>
> Ciao,
>
> --
> Richard Bainter Mundanely | System Analyst - OMG/CSD
> Pug Generally | Applied Research Labs - U.Texas
> pug@arlut.utexas.edu | pug@eden.com | {any user}@pug.net
> Note: The views may not reflect my employers, or even my own for that matter.
