Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!im4u!romp!unisec!dpw
From: dpw@unisec.usi.com (Darryl P. Wagoner)
Newsgroups: comp.bugs.sys5
Subject: Re: A security hole
Message-ID: <1090@unisec.usi.com>
Date: 31 Mar 88 14:06:32 GMT
References: <181@wsccs.UUCP> <722@rivm05.UUCP> <478@minya.UUCP> <892@cosmo.UUCP> <175@pcsbst.UUCP> <544@fig.bbn.com> <4212@ihlpf.ATT.COM>
Reply-To: dpw@unisec.USI.COM (Darryl P. Wagoner)
Organization: UniSecure Systems, Inc. Newport, RI
Lines: 18

In article <4212@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
.In article <544@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
..Every single program that is subject to the "IFS" trick can be
..protected by written a wrapper that sets the environment properly,
..then calls the real program.
.
.But what stops the user from bypassing the wrapper and calling the real
.program directly?

Simply, the problem is setuid bit programs that has a popen in them.

This does a exec of "sh -c program argvs".  This means that /bin/sh
is the problems with IFS.  So how can they bypass?

-- 
Darryl Wagoner		dpw@unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw