[2103] in bugtraq

home help back first fref pref prev next nref lref last post

Re: BUGTRAQ ALERT: Solaris 2.x vulnerability

daemon@ATHENA.MIT.EDU (Adam Prato)
Tue Aug 15 17:58:34 1995

Date:         Tue, 15 Aug 1995 15:07:39 -0600
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Adam Prato <adamp@mickey.ovid.com>
X-To:         Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To:  <199508151659.JAA23492@dilger.Eng.Sun.COM>

On Tue, 15 Aug 1995, Michael Dilger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
>
> > B U G T R A Q   A L E R T                           bugtraq-alert-081495.01
> > [...]
> > Scott Chasin
> > chasin@crimelab.com
>
> Good job Scott.
>
> I tried this attack on /usr/bin/ps and /usr/ucb/ps, and it works on
> both of them.  This makes me think that more than just solaris 2.x
> machines are vulnerable (depending on the /tmp sticky bit).
>
> - --
> Michael Dilger
> Michael.Dilger@Sun.COM
> ENS, Network Security Group
> Sun Microsystems, Inc.

I haven't been able to get this to work. It seems that /usr/bin/ps does not
create any files in /tmp. I had two windows open, one doing a while true ; do
ls /tmp ; sleep 1 ; done. And the other trying this exploit. A ps.* file is
never created (rather no files are created in /tmp). I accidentally left the
exploit running all night and it still didn't work. /usr/ucb/ps however does
create a ps_data file, but it doesnt seem to be changed by psrace.

Any ideas?

Also, does sun plan to release a patch, rather than making the /tmp sticky?

Adam

home help back first fref pref prev next nref lref last post