From owner-freebsd-chat Wed Sep 5 18:24: 9 2001 Delivered-To: freebsd-chat@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id E8FF837B401 for ; Wed, 5 Sep 2001 18:24:02 -0700 (PDT) Received: from hades.hell.gr (patr530-b009.otenet.gr [195.167.121.137]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f861Nu719682; Thu, 6 Sep 2001 04:23:57 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f861OHV03677; Thu, 6 Sep 2001 04:24:17 +0300 (EEST) (envelope-from charon@labs.gr) Date: Thu, 6 Sep 2001 04:24:15 +0300 From: Giorgos Keramidas To: Piet Delport Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Scripts and setuid Message-ID: <20010906042415.A2464@hades.hell.gr> References: <999708032.3b96558062cd2@webmail.neomedia.it> <20010905204055.A268@athalon> <20010905215258.A4304@hades.hell.gr> <20010906005600.A4157@athalon> <00c101c13662$c3716cd0$0364000a@abc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c101c13662$c3716cd0$0364000a@abc>; from list@rachinsky.de on Thu, Sep 06, 2001 at 01:30:30AM +0200 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was trying to come up with a practical example why a setuid shell script is a very unsafe thing to have around. This is what I came up with during the last few hours. To support this opinion, imagine that even with code like below wrapped around your normal shell script, you are never really sure if the script is really very safe. The code tries to minimize the effect the execution environment has on the rest of the shell script, by clearing the environment and executing itself only if HOME is set in the current environment. The only 'saved' environment entry is the one of LOGNAME, which is used further below: #!/bin/sh ( env | grep HOME >/dev/null 2>&1 ) &&\ exec /usr/bin/env - LOGNAME="$LOGNAME" /bin/sh $0 ## Insert your real shell script code below this line. echo "Hello $LOGNAME ..." ## EOF [ Enters the pimply faced youth, the assistant of BOFH, trying to fool around with your newly crafted shell magick. ] It is a shell script remember. To have the interpreter be able to run it, one must have read permissions on it. So the user can 'see' that you base your check for an `empty' environment in HOME being set. He can also see that you are passing $LOGNAME to the `cleared' environment. By playing with various values of LOGNAME and env, I came up with this interesting thing about the above, 'secure environment' script. $ sh hello.sh Hello charon ... $ env - LOGNAME="dear" sh lala.sh Hello dear ... $ env - LOGNAME="HOME" sh lala.sh [ here started the fork bomb ] Can you see why the above code that tries to minimize the effects of the environment to the rest of the shell script, falls in an infinite "exec env ..." loop ? Hint: The value of HOME is *always* unset and the value of LOGNAME is 'HOME' which matches the grep pattern. What I'm trying to prove is that shell scripts rely heavily on the environment passed to them, and they are inherently unsafe, without being setuid. Imagine fooling around with a script like the one above (which is at first glance a very 'secure' script), and also *has* the setuid bit on. Horrors... -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message