Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.internals
Subject: Re: Getting to root when the password has been lost
Message-ID: <1990Oct14.132119.27827@athena.mit.edu>
Date: 14 Oct 90 13:21:19 GMT
References: <15807@shlump.nac.dec.com> <12@tdatirv.UUCP> <1990Oct10.150848.3143@holos0.uucp>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 24

In article <1990Oct10.150848.3143@holos0.uucp>, wdh@holos0.uucp (Weaver Hickerson) writes:
|> anyway, I did a find and found a file that was setuid,
|> belonged to root, and was writable by me.  I wrote a small 'C' program to
|> change the permissions on /etc/passwd to rw-rw-rw (temporarily, of course),
|> linked the program, cat'ted that into the setuid file, and voila.

From the man page write(2) on my BSD 4.3 (well, actually, IBM AOS, but it's
close enough) system:

     If the real user is not the super-user, then write clears
     the set-user-id bit on a file.  This prevents penetration of
     system security by a user who captures a writable set-user-
     id file owned by the super-user.

I consider this to be a very important security feature; the fact that you
were able to use its absence to break into root, after obtaining only access
to a generic non-root account, is good evidence of this.  Does the NCR Tower
not have this in its kernel (if so, I would complain to your vendor!!)?

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710