[203] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Setuid programs run from shell scripts?

daemon@ATHENA.MIT.EDU (Julian Assange)
Thu Nov 17 14:09:46 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. ;-)


home help back first fref pref prev next nref lref last post