Re: BUGTRAQ ALERT: Solaris 2.x vulnerability

[chasin () CRIMELAB COM (Scott Chasin)]

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