Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Sep 2001 04:24:15 +0300
From:      Giorgos Keramidas <charon@labs.gr>
To:        Piet Delport <siberiyan@mweb.co.za>
Cc:        freebsd-chat@FreeBSD.ORG
Subject:   Re: Scripts and setuid
Message-ID:  <20010906042415.A2464@hades.hell.gr>
In-Reply-To: <00c101c13662$c3716cd0$0364000a@abc>; from list@rachinsky.de on Thu, Sep 06, 2001 at 01:30:30AM %2B0200
References:  <999708032.3b96558062cd2@webmail.neomedia.it> <20010905204055.A268@athalon> <20010905215258.A4304@hades.hell.gr> <20010906005600.A4157@athalon> <00c101c13662$c3716cd0$0364000a@abc>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010906042415.A2464>