[202] in bugtraq
Re: Setuid programs run from shell scripts?
daemon@ATHENA.MIT.EDU (Julian Assange)
Thu Nov 17 13:55:10 1994
Date: Fri, 18 Nov 1994 02:56:11 +0100
From: Julian Assange <proff@suburbia.apana.org.au>
To: Karl Strickland <karl@bagpuss.demon.co.uk>
Cc: Quentin Fennessy <Quentin.Fennessy@sematech.org>, fred@nasirc.hq.nasa.gov,
mcn@c3serve.c3.lanl.gov, bugtraq@fc.net, Quentin.Fennessy@sematech.org
In-Reply-To: <199411160855.IAA03595@bagpuss.demon.co.uk>
> > So the script suid has to take
> > preference.
>
> why?! i dont follow the logic.
>
Well, I see the logic in that one has to take precedence. Personally I
would have gone for having the bins suidbits been honnored, as your bins
do not reference the script i.e are not expected to know what perms it
has, and futhur, are more likely to be dependent on any suid nature they
may have. Also, in terms of time-precedence, obviously the scripts inode is
looked at before the bins.
There is a security issue here when you add groups. If the binrary is
setgid & setgid and the scripts s[ug]id bits take precedence over the
binary, then we can "knock off" either the sgid or suid of the binary and
replace it with whatever we can put on the script. This could have far
reaching consequences if the target binary expects BOTH a particular euid
and egid to be secure (or neither).
You might say that there is no issue here, because we can "add" groups. i.e
put the binary's sgid into the suplimental gid list and our problem is
solved. Almost. Your default file creation gid is still going to be the
egid, and you can have only one. Likewise tests based on getegid() will give
unpredicted/false results.
Of course, to make things really interesting, we could have n files,
comprised of n-1 setuid/setgid scripts and 1 setuid/setgid binary, with
each script calling the next as its #! argument and the last calling the
binary. ;-)
Proff
