Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!ll-xn!ames!ptsfa!ihnp4!ihlpl!psfales
From: psfales@ihlpl.UUCP
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: UNIX file setuid sucurity hole?
Message-ID: <1911@ihlpl.ATT.COM>
Date: Sat, 14-Mar-87 00:27:39 EST
Article-I.D.: ihlpl.1911
Posted: Sat Mar 14 00:27:39 1987
Date-Received: Sat, 14-Mar-87 20:12:15 EST
References: <2168@ncoast.UUCP> <695@aw.sei.cmu.edu.sei.cmu.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 20
Xref: utgpu comp.unix.wizards:1384 comp.unix.questions:1369
Summary: Another way...

In article <695@aw.sei.cmu.edu.sei.cmu.edu>, pdb@sei.cmu.edu (Patrick Barron) writes:
> 
> Of course, if you are running on a system which does allow random users to
> use chown (I've never heard of such a beastie, but just for the sake of
> argument...), I'd have have chown clear the 6000 bits of a file's protection
> as part of the chown process (and, of course, you couldn't reset them, since
> you can't chmod a file you don't own....)

On my system which I assume is running more or less vanilaa AT&T UNIX
(uname -a says "uts ihlpl 5.2.5 5 5890") it works exactly this way.  I
just tried copying /bin/cat to /tmp and making it setuid to me.  That worked
fine.  Then I did a chown (random users can chown) to give it to someone 
else and the system cleared the setuid bit.

Of course, this still does not address the trojan horse problem.
-- 
Peter Fales		UUCP:	...ihnp4!ihlpl!psfales
			work:	(312) 979-7784
				AT&T Information Systems, IW 1Z-243
				1100 E. Warrenville Rd., IL 60566