Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!ncar!oddjob!gargoyle!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.bugs.sys5 Subject: Re: A security hole + FIX(?) Message-ID: <4210@ihlpf.ATT.COM> Date: 30 Mar 88 23:38:17 GMT References: <181@wsccs.UUCP> <722@rivm05.UUCP> <478@minya.UUCP> <892@cosmo.UUCP> <175@pcsbst.UUCP> <766@senilix.liu.se> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 35 In article <766@senilix.liu.se> mikpe@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." / (_