Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!umix!uunet!mcvax!enea!liuida!mikpe From: mikpe@senilix.liu.se (Mikael Pettersson) Newsgroups: comp.bugs.sys5 Subject: Re: A security hole + FIX(?) Message-ID: <782@senilix.liu.se> Date: 2 Apr 88 01:51:23 GMT References: <181@wsccs.UUCP> <722@rivm05.UUCP> <478@minya.UUCP> <892@cosmo.UUCP> <175@pcsbst.UUCP> <766@senilix.liu.se> <4210@ihlpf.ATT.COM> Organization: CIS Dept, Univ of Linkoping, Sweden Lines: 54 In article <4210@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >In article <766@senilix.liu.se> mikpe@senilix.liu.se (Mikael Pettersson) writes: > >>[ I argued that renaming /bin/sh to /bin/.real-sh and having /bin/sh be a >> small C program that resets IFS before exec'ing /bin/.real-sh could be >> a reasonable way to close down the IFS hole for non-source systems. ] > >This doesn't fix the problem. What stops me, Joe User, from doing an > >$ exec /bin/.real-sh > >and bypassing your /bin/sh program?? Nothing, but that's not the problem here. The problem is the use of popen() in set-uid programs. Ok, here's the full story: Suppose Joe User executes /bin/mail or some other possibly set-uid program that might need to communicate with a trusted subprocess. This subprocess is often created with a call like popen("/foo") with /bin or /usr in . To do this, popen() forks off an instance of /bin/sh(*) giving it "/foo" as an argument. The intention is to have the shell(*) interpret IO-redirections and whatever shell meta-syntax we wish to use for us. Now, suppose the malicious user had reset IFS to "/" and exported it. This means that the shell(*) will inherit IFS="/". Now, it's easy to see what happens: the shell(*) will strip out the /-es from , leaving the argument looking like "usr bin foo" instead of "/usr/bin/foo". If there is a program called "usr" in Joe User's PATH *IT* will be executed with the uid intended for the trusted program, i.e., Joe User is root. How do we prevent this? We can't change popen() to reset IFS and recompile all sources with our new C-library since most systems don't have source to begin with. My fix will, I believe, stop all attempts to use *this* hole with minimal changes to the system. You don't even have to wait for your vendor to do it for you since all it takes is a small (<10 lines) C-program. (One problem might be that not all systems have putenv() in libc.a. In those cases one has to improvise, but it's still just another trivial 3-4 lines.) >I was thinking that if you did a setuid/setgid on the new /bin/sh, this >might be able to fix the problem. I don't think so, since then the set-uid program doing the popen() would create a child with wrong uid, like uid=sh instead of uid=root. > _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 >' ) ) "The secret compartment of my ring I fill > / / _ , __o ____ with an Underdog super-energy pill." >/ (_