System V.2.2 setuid() broken

[Kenneth Almquist]

> In article <1305 at basser.oz> boyd at basser.oz (Boyd Roberts) writes:
>> I'm root and I run a non-root setuid executable.  Then I want
>> to fork() a shell and do the usual:
>>
>> 	setuid(getuid())
>>
>> Of course, I get EPERM, because setuid() is broken.  Now is this
>> a generic System V bug.  I think it is.  Clarification please?

This bug has been in AT&T UNIX (System V and its predecessors) for quite
a while.  I found it last summer when I was working for AT&T, and my
supervisor told me to forget about trying to get it fixed since it was
in the machine independent part of UNIX.  So I made my program setuid
to root rather than using a less dangerous uid.  This may work for you
as well.

I will devote the rest of this article to correcting John Haugh's
comments.  Uninterested readers hit `n' now.

> consider, running the a.out SUID sets the EFFECTIVE UID to the
> non-root user.  getuid(2) returns the REAL UID which equals
> ROOT.  and from the manual
> 
> 	Setuid (setgid) will fail if the real user (group) ID
> 	of the calling process is not equal to uid (gid) and
> 	its effective user ID is not super-user. [ EPERM ]
> 
> the real user ID is ROOT and the uid is ROOT.  however, the
> effective user ID is not ROOT, so the call fails with EPERM.

You misread the manual.  The effective user ID is equal to uid,
so the call to setuid should succeed.

> this `feature' prevents a trojan horse from doing a
> 
> 	if (getuid () == 0) {
> 		setuid (0);
> 		chown ("/bin/sh", 0, 0);
> 		chmod ("/bin/sh", 04711);
> 	}
> 
> thereby giving you the famed password free su command.

A version of UNIX in which the "chmod" system call didn't work would
also be safe from this particular attack on security.  And speaking
of security, I've come up with a way to system crackers from logging
into your system even if they steal one of your user's passwords.
The technique?  Remove the login program. :-)

I hope you don't really think that UNIX will protect you if you run
a Trojan horse program, setuid bugs or not.  The only way to protect
yourself from Trojan horse programs is not to run them, especially if
you are superuser.
				Kenneth Almquist