| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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 |