A security hole + FIX(?)

[00704a-Liber]

In article <766 at senilix.liu.se> mikpe at senilix.liu.se (Mikael Pettersson) writes:

>If you don't have source, you could do what I did on a SVR2(-like) machine
>I'm administrating. Write a small program that simply does:
>		putenv("IFS= \t\n");
>		execv("/bin/.real-sh", argv);
>and call it /bin/sh. (you mv'd /bin/sh to /bin/.real-sh before of course!).
>This works Ok on my machine. Does anybody know of any reasons why somehting
>like this shouldn't be done?

This doesn't fix the problem.  What stops me, Joe User, from doing an

$ exec /bin/.real-sh

and bypassing your /bin/sh program??


I was thinking that if you did a setuid/setgid on the new /bin/sh, this
might be able to fix the problem.  But the only solution that I have
thought of (so far) won't work.

What I thought of doing is changing the file attributes to the following:

---x--s--x	bin	sh		sh
---x--x---	bin	sh		.real-sh

but the problem is that Joe User (uid=foo, gid=bar) would be running
.real-sh as egid=sh, not as egid=bar.  The only way that I can think of
that would fix this problem would be to modify the source of .real-sh, but
then we wouldn't need the front end to the shell in the first place.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah