A security hole + FIX(?)

[Mikael Pettersson]

In article <4210 at ihlpf.ATT.COM> nevin1 at ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <766 at senilix.liu.se> mikpe at 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("<full-path>/foo") with /bin or /usr
in <full-path>. To do this, popen() forks off an instance of /bin/sh(*)
giving it "<full-path>/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 <full-path>, 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."
>/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

-- 
Mikael Pettersson           ! Internet:mpe at ida.liu.se
Dept of Comp & Info Science ! UUCP:    mpe at liuida.uucp  -or-
University of Linkoping     !          {mcvax,munnari,uunet}!enea!liuida!mpe
Sweden                      ! ARPA:    mpe%ida.liu.se at uunet.uu.net