Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Aug 11, 2003 at 04:00:40PM +0200, Emile van Bergen wrote:
> On Mon, Aug 11, 2003 at 09:28:42AM -0400, Matt Zimmerman wrote:
> > setuid results in even more problems than setgid. Given access to the
> > game uid, the user can modify the wrapper program (because they own it)
> > and from that point forward, any user who runs the game is compromised.
>
> The point is that the user doesn't get control over the game uid, because
> the setuid + wrapper that sets the real uid, etc. provides a barrier to
> the invoking user. We have to trust such barriers; they are required in
> the unix design.
>
> If a user could make any setuid binary do arbitrary things, no matter
> whether it's correctly written, then it's a kernel bug and we are in much,
> much bigger trouble.
I don't follow. The wrapper is running with uid games, and it exec()s the
actual game. So the game is running with uid games, exactly as if the game
itself were setuid, and if the game is exploited, uid games is compromised
(and so is the wrapper).
The only barrier I see is that it would clean the environment variables.
Yes, this is a popular attack vector, but it is by no means the only one.
> The idea is that the wrapper must be trusted to be able to guarantee
> dropping all permissions inherited from the invoking user and setting all
> uids (saved, effective, real) to the per-game uid. After this, the game
> cannot do anything as the invoking user or to his files. That's the whole
> point.
>
> Setgid is a bigger problem because the process retains the permissions
> over the invoking users files and gains additional permissions. Not so
> with this scenario.
>
> After completely switching to the game uid, if mere user input is enough
> to have the game run arbitrary code under its per-game uid and do the same
> when the next user runs it, it won't be able to harm that user in any way,
> simply because that game uid can't do anything to any user at all.
As I said, the per-game uid would own the wrapper script, and it is far
easier to replace that with a trojan than to try to exploit the game from
within.
--
- mdz
Reply to: