Subject: Removing dm(1)
To: Jon Ribbens <firstname.lastname@example.org>
From: Curt Sampson <email@example.com>
Date: 11/18/1997 08:54:43
I'm copying this to a couple of user lists to give the users of
dm(8), if there are any, a chance to speak out.
Security issues aside, this program looks entirely obselete. It
was designed for use in an age when computing resources were scarce,
CPU and memory were expensive, most people did not have a computer
capable of running Unix dedicated to them, and text games were
exciting. There aren't a lot of 30-user VAX 11/780 systems out
there these days that are getting bogged down by a dozen people
playing rogue. (There aren't a lot of systems still out there that
would even notice a dozen people playing rogue.)
Also, keep in mind that if you have any Internet or other outside
connectivity at all, or even e-mail, you can easily just grab
another copy of the game binary of your choice and play it anyway.
So I'm going to propose that we simplify life and remove dm(8).
Does anyone have any objections to this?
Curt Sampson firstname.lastname@example.org Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite myst, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.
On Tue, 18 Nov 1997, Jon Ribbens wrote:
> Date: Tue, 18 Nov 1997 15:22:10 +0000
> From: Jon Ribbens <email@example.com>
> To: tech-security@NetBSD.ORG
> Subject: Re: bin/4489: /usr/games/fish allows setuid games binaries to be created by unprivileged user
> Mika Nystroem <firstname.lastname@example.org> 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.
> \ // Jon Ribbens // 100MB virtual-hosted // www.oaktree.co.uk
> \// email@example.com // web space for 99UKP //