System Security (was: Re: [MUD-Dev] players who "take away from the game")

[cg at ami-cg.GraySage.Edmonton.AB.CA]

[Eli Stevens:]

> This got me wondering...  :)
>
> What precautions should be taken when writing a MUD codebase from scratch?
> Are most security holes that a MUD box might have at the OS level, or does
> having a program like a MUD running open up opportunities that would not
> otherwise exist (assuming that the ability to issue OS commands and such is
> not a feature)?

Aha! A technical issue! :-)

Having a MUD running isn't a problem if you are careful in what you let
the MUD server do. Obviously! The main thing is likely to be that of
system and communications load. If you are careful to *not* provide any
ways by which MUD players can issue system commands, there shouldn't
really be any issues outside of the MUD itself. A MUD server simply
presents a socket that people can talk to. If it never, however indirectly,
allows stuff that comes from client sockets to end up uneditted in a
system command, then it should be safe.

Sometimes, however, the nature of how the MUD works requires that some
portions of the MUD be able to issue system commands. For example, back
when my server was AmigaMUD, I used to issue system commands from the
MUD code in order to deliver email from MUD characters to normal email
addresses. However, the player only controlled the destination email
address, the email subject, and the email contents. The MUD code did
nothing with any of those, other than to check that they were properly
formed (in the case of the subject and destination). So, that should
have been fairly safe.

However, to show how careful you have to be, I think I just realized that
I likely wasn't checking things carefully enough, and it could have been
possible for someone to format my server hard drive for me. With the
spread of the internet, I don't need to do that email/news stuff in my
MUD anymore, so its not there. In fact, I don't think I currently use
the ability to run system commands for anything other than an automated
backup system, which includes only fixed commands.

> Also, I am very curious about Kanga.Nu being "regularly attacked."  Would
> you (JCL or others) be able to describe the kind of attacks these usually
> are?  How you might prevent them from working, etc.  :)

Likely some fairly standard internet attacks at mostly well-known weaknesses.
I'm not a security guru by any means, so I'll leave any more detail to
JCL, if he even wants to be more specific. Read newsgroup comp.risks for
high-level reports, and computer security newsgroups for lots of details.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev