Mika Nystroem <mika@saxophone.cs.caltech.edu> wrote:
> >Synopsis:       /usr/games/fish allows setuid games binaries to be created by unprivileged user
> >Confidential:   yes
> >Severity:       critical

> 	/usr/games binaries are invoked by dm, which is setuid games.
> fish doesn't change its uid back (this is my understanding of how this
> works, anyhow).  By using a permissive SHELL (at least I had to change
> it from /usr/local/bin/tcsh), it is possible to make fish, when it lets
> you read the instructions, spawn vi.  From vi, you can enter ex-mode
> and cp /bin/sh to /tmp and then chmod 4711 /tmp/sh.  This gives a 
> setuid games shell.  From here, an intruder could implant a trojan 
> in /usr/games/fortune, for instance...

Both 'more' and 'less' allow you to type '!sh' ;-).

It's not just 'fish'. 'backgammon', 'larn', 'quiz' and 'wump' have the same
problems. (And that's just checking for 'system' and 'popen', without even
considering buffer overflows or any of the other zillions of possible security
holes.) 'larn' only uses 'system' if you win, which is amusing - you have
to win the game in order to hack the computer ;-).

The only games that set the uid back are adventure, atc, hak, mille,
robots and sail.

IMHO the 'dm' system is completely broken. Preferably it should be abandoned
completely. At the least, every single game needs 'setuid(getuid())' adding.
Does anybody actually use the games-restriction facilities of 'dm'?

This isn't just an esoteric problem. I wonder how many people have
'fortune' in their /etc/profile? Wouldn't take you long to get a root shell.

Cheers


Jon
____
\  //    Jon Ribbens    // 100MB virtual-hosted // www.oaktree.co.uk
 \// jon@oaktree.co.uk //  web space for 99UKP //