Issues in MUSE Security David B. Albert April 6, 1994 -------------------------------------------------------------- Outline of Contents I. Introduction II. Access and Accountability A. Internet Access B. Guest Account Access C. MUSE Access III. MUSE Database Security Issues A. Password Security B. The users attribute C. Empowered objects 1. Power Tools 2. Parser Problems a. Unintended v(0) evaluation b. Insufficient number of % signs D. Server bugs E. Parent Objects IV. Database Size V. Spoofing VI. Security from a User's Point of View A. Locking objects B. Parent objects C. Robots D. Privacy VII. Host Computer Security VIII. Conclusions and Recommendations A. Access Recommendations B. Server Operation Recommendations C. Server Modification Suggestions Bibliography Acknowledgements -------------------------------------------------------------- I. Introduction With the proliferation of public services on the Internet, one frequently recurring theme is the question of security. How secure is each service from unauthorized use, from negligent or malicious destruction of data, and from violations of privacy? Some security problems, such as the use of insecure passwords, are common to most networked services and therefore have been discussed at length in many forums. Specialized services, however, carry with them their own sets of less well known security risks. This paper discusses the security issues of a class of service known as a MUSE, or a Multi-User Simulation Environment. A MUSE consists of a server program running on the Internet, and an accompanying database. Users connect to the server using either telnet or a specialized client program, log in to a user ID or "character" in the MUSE database, and then can communicate with other users logged in simultaneously. Users who have been granted the appropriate privileges may modify or add on to the database, which on most MUSEs is used to simulate a virtual world. In MUSE jargon, users can build rooms and objects in the world, which are then owned by their characters. Characters can visit each others' rooms, and may link their rooms together. As with any large computer system, a MUSE is run by System Administrators, known on most MUSEs as Directors. These users are granted powers, similar to those of the superuser on a UNIX system, to alter any object in the database regardless of which character owns it. A MUSE character is also an object in the database; thus, this power extends to causing a character to perform an action or to run a program, in much the same way that the UNIX "su" command allows the superuser to execute a command as if it had been typed by another user. An unauthorized user gaining System Administrator powers can peruse, alter, or manipulate the database freely. This paper will address several issues in MUSE security. First, it will cover the problem of unauthorized access to the system, a problem compounded by the existence on many MUSEs of anonymous Guest characters to which anyone is free to connect, and of the availability of public-access Internet sites from which to do so. Second, it will describe and document bugs and loopholes in the server which can be exploited to gain access to System Administrator powers. Also covered are the problems of spoofing, in which one character can pretend to be another, and of harassment of users by one another. This paper will also present suggestions for security improvements on existing systems, and will discuss the benefits and pitfalls of suggested changes. II. Access and Accountability The first step in any security system is accountability. If an online user can be traced to a real individual, the chance that the user will exploit existing security holes is lessened due to the fear of being caught. Unfortunately, MUSE users can be hard to trace. Any individual with access to an Internet account can use the telnet protocol to a MUSE by specifying its address, which consists of the fully-qualified Internet host name of the computer it is running on, and the port to which it is attached. For example, MicroMUSE at MIT runs at chezmoto.ai.mit.edu, port 4201. There are client programs, such as TinyFugue for Unix and TINT for VAX computers, that provide a cleaner interface than telnet and that permit activities such as session logging and simultaneous connection to multiple MUSEs. Individuals who cannot compile their own copy of a client program can connect to one of several sites that provide guest access to a client. Some people connect to a MUSE via a Freenet, a service provided locally in many cities throughout the country. Freenets do not typically offer unrestricted access to the Internet, but may provide access to a MUSE as a menu choice. And some people find roundabout ways to connect, through public-access sites at Universities or libraries around the country, or through other Internet services via back doors that the service providers do not always realize exist. Regardless of the exact connection method, there is always either a two-step or three-step process to connect to a MUSE. A user first connects to a computer on the Internet; from there some users connect to a guest account running a MUSE client; finally a user connects and logs in to the MUSE itself. Anonymous access may be permitted at any of these steps, and even when it is not, people frequently use borrowed or stolen accounts not registered in their own names; therefore, tracing a MUSE character back to the actual person who is controlling it can be difficult. II. A. Internet Access At the Internet level, if a user logs in to a properly-registered account at a university, business, or other organization, the connection is logged and may be traced. But if the user has given false information when registering for an account (which is sometimes possible on Freenets that provide public accounts), if the user logs in to the account of a friend, or if the user steals or guesses someone else's password, then accountability may no longer be possible. At best, the offending account can be disabled, but the individual behind it can often switch to another account. If a user connects to the Internet through a public-access terminal in a library or terminal cluster, tracing the user would require actually spotting the person at work. Although such a trace might be carried out in the event of a national emergency, the energy required is generally far greater than that available for unauthorized use of a non-military computer system, and all that can generally be done is to close off such access sites as they become known. This action carries the unfortunate consequence of denying access to individuals using the system properly, and some sites are reluctant to do so. From the point of view of a MUSE System Administrator, another option is to prevent access to the MUSE from such publicly- accessible sites, which is possible on a site-by-site basis but which requires waiting until such sites are identified, and which means that a break-in may already have occurred before the site can be locked out. Site-blocking is likely to become less and less effective over time; the rate at which new public-access sites are brought online is increasing. II. B. Guest Account Access Guest access to a Unix account running a TinyFugue client is by nature anonymous. Although a user must first log in to an Internet host before connecting, all that can be logged by the guest account is the hostname from which the user is connecting; telnet does not currently contain authentication procedures requiring that the userid be sent as well. Thus, the process of tracing a guest user back to the userid of the person connecting requires the help of the remote system administrator, who may be able to check local logs to determine who was using telnet at the same time that a user connected to the guest account. Such cumbersome methods have sometimes been used with success, but more often than not, the best available remedy is to prevent access to all users from the offending host. This restriction again places an unfortunate restriction on innocent users of the same system, and again can be used only after the fact; it does not help identify the individual. On some occasions, particularly if the guest user is connecting from a small computer, or at an odd hour, the UNIX finger command can be used to trace the user. If there is only a single non-idle user logged in to the host at the time, then identification has occurred. If there are a small number of users, and the guest logs in multiple times, triangulation is sometimes possible by repeatedly checking the output of the finger command to see which user was logged in each time. If the user can be traced, a letter to the offender's system administrator is often sufficient to have the account disabled and the offender stopped, but again, only after the user has already broken in. II. C. MUSE Access A user can log in to a MUSE either as a registered character, or as a Guest (anonymous) user. Both methods present accountability problems; although the problems are more obvious with Guest users, registered characters may also be vulnerable to anonymous use, and no MUSE can consider itself completely safe from unauthorized access even if Guest logins are disabled. When a MUSE permits Guest access, as do most MUSEs currently running, any user may connect as "Guest", and is known online by a generic name (typically Guest1, Guest2, etc.; although some MUSEs provide more interesting names the anonymity remains the same). Even if Guests are asked to identify themselves when they log in, there is no guarantee that they will do so truthfully. The problem of tracing a Guest who creates problems or exploits security holes is discussed in the previous subsections; a trace will sometimes succeed but there is no guarantee, and in either case damage may already have been done. The only way to prevent the problems of anonymous Guests is to prohibit Guest access entirely, or at any rate to restrict Guests to a very limited subset of options (such as leaving a message for an administrator or registering for a character). When restricting Guest logins, some methods are more secure than others. The most secure method is to modify the MUSE server to prevent Guests from logging in. Some MUSEs allow Guests to log in, and then use on-line methods to send them a message, disconnect them, or disable their ability to perform certain commands. This method has the advantage of flexibility (for instance, Guests may be selectively granted access if they can verify their identity to the satisfaction of an administrator). The drawback is that a guest typing fast enough, or using a client that can send pre-typed commands rapidly to the server, may be able to issue a few commands before being disabled. Those commands may be enough to harass users or even to exploit a security hole. The problems associated with registered users are at once more subtle and more well-known, as they mirror problems associated with computer accounts everywhere. One person may use another's account, either by mutual agreement or through password theft. A registrant may falsify I.D. when first requesting an account. Or a duly registered user may cause trouble and then claim that someone else was using the account. Finally, in the absence of exhaustive, detailed log files of everyone's activity, it may not be possible to know which user has committed an act of vandalism or harassment, even if every user can be identified. Unfortunately, none of these problems lends itself to a perfect solution. All users should be educated about the need for password security, after which they can be held accountable for actions committed using their account, regardless of who was actually using it; but the reality is that some will continue to choose passwords that are easy to guess, or inadvertently leave their passwords where others can find them, and others will let friends use their accounts. The best one can do is to continue the educative effort, while treating each situation individually as problems arise. Problems with falsified I.D. at the time an individual requests a character can be held to a minimum by giving out passwords only via e-mail, rather than online, thus ensuring at least that the user's e-mail address is genuine. If additional security is necessary, registration can be handled in person or by U.S. mail, with a photocopy of a picture I.D. required before a MUSE character is created. The issue of logging commands to a file is a tricky one. Unlike most computer applications, a MUSE is seen as a "world", albeit a virtual one, and users often carry on private conversations online. Logging all typed commands would be a gross violation of privacy. On the other hand, some forms of vandalism and harassment can be hard to trace without such logs. Some highly sensitive commands are already logged by most MUSEs; modifications to the server could be made that would log more such commands, without logging direct communication between users. However, if too many commands are logged, the log files may become so voluminous that they fill up available disk space. Each MUSE administrator will need to balance local resource availability with local security needs when determining what measures to take. III. MUSE Database Security Issues The database is the part of a MUSE that gives each its own character. MUSE servers are similar (even identical) one to the next, but databases are unique. A MUSE database consists of a collection of records, or objects, of different types: users, rooms, exits between the rooms, and things in the rooms or in users' possessions. Each object has an owner (who is a user), just as every Unix file has an owner. Objects may contain complex code that runs a program, or that responds to commands or to the actions of other objects. With a few exceptions, most users are permitted to modify and rearrange only their own objects. MUSE administrators, however, need to perform such tasks as creating new or deleting old users, monitoring system resources, and supervising the use of the MUSE; for these and similar purposes, administrators need the ability to control objects belonging to other users. The design of the MUSE server was conceived with an emphasis on flexibility. On every MUSE, at least one System Administrator always has the power to do absolutely anything to the database, and can allocate powers and responsibilities to other users as necessary, so that each administrator has the powers required to perform his or her duties. Care was taken in the design to ensure that users can perform all necessary functions, including programming creative and interesting projects, without the need for special powers, but the MUSE is flexible on that point as well, providing for "project" or "group" characters that have a small number of powers tailored to their particular needs. With flexibility of design, comes increased risk that an unauthorized user will gain access to powers that were not intended for his or her use. Realistically, one must expect security loopholes to exist in any system; a MUSE contains at least its fair share. Although most of them are plugged as they are discovered, there exist certain types of security holes that are prone to recur because of the way objects are programmed in MUSEcode, the MUSE programming language. Most of this section is dedicated to a detailed discussion of this type of problem. This section will of necessity be technical in nature and will assume a working knowledge of MUSE coding and general concepts in MUSE administration. For more information on MUSE programming, consult the documentation accompanying the MUSE server distribution [1], or the MUSE Manual [2]. This section covers only security holes involving the use of restricted functions by otherwise-authorized MUSE users. Such functions include use of the @class and @empower commands, the modification and triggering of objects owned by other users, unrestricted use of @teleport, and the ability to read and examine attributes on objects belonging to other users. Other types of security holes, such as the improper use of spoofing, and the use of non-restricted commands in improper ways, are discussed in a later section. III. A. Password Security Passwords are stored on a MUSE attribute in encrypted form. This attribute may be read only by the primary System Administrator (the Boss character, normally character #1); it is also available to anyone with read access to the online database file. As with passwords stored in the file /etc/passwd on a Unix system, encrypted passwords may be vulnerable to concerted attack using a program such as crack, widely available on the Internet. While such attacks will not be successful if non-dictionary-word passwords are chosen, it is well known that not all users will pick secure passwords. Thus it is essential that the database file not be publicly readable. In addition, it is unwise for the #1 character to be used by a real person, or to own any empowered objects; as will be explained below, certain types of bugs may make an empowered object subject to exploitation. When the @newpassword command is used by an administrator to reset a user's password, the new password is stored in plaintext rather than in encrypted form. Thus, whenever @newpassword is used, the owner of the changed account should be told to change the password again using the regular @password command. The sensitive log file also records all passwords created with @newpassword and with @pcreate. This file should not be publicly readable, and in addition the *log_sens channel online should be carefully monitored to ensure that no unauthorized characters are listening before @newpassword or @pcreate are used. III. B. The users attribute On each character is a users attribute, which can be set only by those administrators with the WizAttributes power. The attribute may be set to contain a list of other users. Any user who appears on a users list for a particular character controls that character completely, meaning that the user may @force, @chown, or modify any object owned by the other character. Most importantly, any powers that the character has are available to any user on the character's users list. This fact implies that no user should ever be placed on the users list of an administrator with more powers than you intend for the former to have. Indeed, it is safe to assert that no regular user should ever be on the users list of any administrator. However, care must be taken as well with respect to Group characters, some of whom may have been granted powers, to ensure that only trusted users are given access to the character, whether by knowing the password or by being placed on the users lists. III. C. Empowered objects Directors and other MUSE Administrators have access to privileged functions; so do any of their objects that have been empowered by setting the "Inherit" flag on the object. This functionality has a variety of uses; chief among them is that it enables administrators to add new, general-use commands to the Universal Zone Object (rather than having to add them to the MUSE server, which is a longer and less- easily-mutable process). For example, the UZO contains the following attribute-command: Va:$@selfboot:@boot %#;@boot %#;@boot %# which creates the @selfboot command that any user can type to log out multiple times in the event that previous sessions did not properly disconnect. While such a command could be programmed into the server, that would have required writing many lines of C code, recompiling, and shutting down the MUSE in order to bring up the new version. By contrast, adding the above command took less than a minute, was available immediately, and can easily be modified or removed. The command in the previous example works only because the UZO object has the power to use the @boot command, which requires a special privilege; to be useful, the UZO must be an empowered object. Unfortunately, this requirement also creates opportunities for serious security holes. The rest of this section will deal with specific examples of such holes, known colloquially as "wizbugs" because they are bugs that give people "wizard" (administrator) powers. But first let me make clear that I am using the UZO only as an example of an empowered object. Any object that is owned by an administrator and that has the "Inherit" flag set may be vulnerable to the same sort of abuse as the UZO, and the problem of searching for all such objects on a large database and checking each to see if it contains a bug is immense. Those individuals establishing new MUSEs should establish procedures to double-check all empowered objects as they are created. III. C. 1. Power Tools Consider an empowered object with the following attribute-command: Va:$xxx *:%0 If someone within the triggering scope of this object types any command at all preceded by the keyword xxx, then the empowered object will execute that command. (This is not quite accurate; see below for a discussion of the %0 versus v(0) syntax, but it will do for now.) For example, typing xxx @class *Mike=Administrator will result in the user Mike being classed Administrator. It goes without saying that such a command should not be placed knowingly on any empowered object. However, such a command might be placed on an object unwittingly (through a typographical error), or maliciously (either by someone who finds another bug and uses it to plant such commands for future use, or by someone who owns a parent of an empowered object (see section III. E., below, for more on parent objects). Finally, on some MUSEs, administrators who are otherwise reliable have been known to give their friends so-called "power tools", empowered objects with commands programmed on them similar to the one in this example. Such an object, even if originally intended for use by a single, trusted person, may accidentally fall into the hands of someone else. Although the ulock register provides some protection in this case, there is still the matter of accountability. If someone needs such powers on a regular basis, they should be granted the powers using the standard MUSE tools, @class and @empower. Providing someone with a general- purpose "power tool" is very dangerous. III. C. 2. Parser Problems The remaining bugs in this section all fall into the general category of "parser problems". Unfortunately, the MUSE parser was not particularly well designed, having been programmed in stages by different people, all of whom labored under the necessity of retaining backwards-compatibility with previous versions. Most security holes discovered and exploited by MUSE crackers are due to attribute-commands containing function calls that are parsed in an unexpected manner. This section provides examples and brief descriptions of several bugs often found on empowered objects. Whenever the function v(x) has a value for some x (v(n), v(N), v(0), v(1), etc.) the parser also will recognize %x (%n, %N, %0, %1, ...) as a substitute, but the latter format will have all semicolons and commas removed from its return value. Most of the security holes described in this section can be avoided by using this latter format, at the expense of preventing strings with semicolons and commas from being properly processed; the reason why this removal is desirable will become clear in the specific examples shown below. III. C. 2a. Unintended v(0) evaluation The function v(0) evaluates to the first argument of an attribute-command. The addition of square brackets, [v(0)], causes the function to be evaluated immediately upon being recognized by the parser, during initial function-evaluation, rather than during the sub-evaluation stage. Consider the following example: Va:$yes-no *:@switch v(0)=yes,@emit yes, {@switch [v(0)]=no,@emit no} On the surface, this attribute-command appears to have the following On the surface, this attribute-commabehavior: if yes-no yes is typed, the object on which this command is programmed emits yes; if yes-no no is typed, it emits no; and if yes-no is typed, the object does nothing. In fact, this object can be used as a general power tool. If a user types: yes-no xxx;@force *Robin=@class *david=official;@emit Hi then the parser will evaluate [v(0)] before applying the @switch command, causing the object to attempt to execute the following command: @switch v(0)=yes, @emit yes, {@switch xxx; @force *Robin=@class *david=official; @emit hi=no,@emit no} and then, since v(0) is not equal to yes, to execute the following sequence and then, since v(0) iof commands: @switch xxx (which does nothing) @force *Robin=@class *david=official (which makes David an official) @emit hi=no,@emit no (which emits hi=no,@emit no) In this case, the solution to this problem involves replacing [v(0)] with In this case, the solution to this probv(0). Given the attribute- command: Va:$yes-no *:@switch v(0)=yes,@emit yes,{@switch v(0)=no,@emit no} then the same input as above causes only the following command executions: @switch v(0)=yes,@emit yes,{@switch v(0)=no,@emit no} @switch v(0)=no,@emit no with the net result that nothing is done. Many problems can be avoided by using v(0) instead of [v(0)] whenever possible; in any case, %0 should be used whenever removal of commas and semicolons is not a problem. Notice that the above input example could not cause command-execution if it did not contain semicolons. III. C. 2b. Insufficient number of % signs There is one situation in which the use of %0 instead of v(0) does not help. Because %0 does not strip out brackets, parentheses, or the / symbol, the following attribute command on a privileged object can be exploited to read hidden database attributes: Va:$print *:@emit %0 If a user types print get(#123/vx), the object will first evaluate get(#123/va), returning whatever the value of the vx attribute is on object #123, and then will emit that value. Notice that the command print get(#123,vx) will not work, because the comma is removed. To avoid this security hole, the above command may be programmed as follows: Va:$print *:@emit %%0 The % symbol is a parse-inhibitor (much like the "quote" function in LISP). In this example, when the input @emit %%0 is first parsed, it evaluates to @emit %0 regardless of the input value. The input is then substituted for %0 when @emit is executed, resulting in an exact-match print of the input. Problems such as the above have been observed throughout many MUSE databases. All commands programmed onto user-accessible privileged objects must be carefully checked for %-bugs. Future versions of the server should be reprogrammed to help eliminate some of these holes, by causing the %0 construct to strip parentheses as well as the semicolons and commas it already removes (or perhaps to replace parentheses with harmless symbols such as < and >, rather than simply removing them entirely). III. D. Server bugs Now and then, a bug in the current version of the MUSE server is discovered that permits a user to gain unauthorized privileges. These bugs are routinely fixed as they are found, but it would be unreasonable to expect that all of them have already been discovered. In any system as large as a MUSE server, bugs are certain to exist. This paper cannot, for security reasons, describe bugs that are currently known and that have not yet been fixed. Nor would such a list be particularly useful, since the fixes are imminent. However, I will describe two bugs that are fixed in the latest version, to give readers an idea of the range of bugs that could be present, and to suggest the types of problems that MUSE operators should be on the lookout for. The first example is of a spoof-protection bug in the @oemit command (see section V for a description of spoofing and spoof-protection). While @emit restricts a user from emitting text beginning with the name of another user, @pemit permits the user to send such text to any object the user controls (including the user's own character). Thus, the command: @pemit me=Joe says "hi" is legal for any user. The behavior of @oemit was programmed to behave the same way, overlooking the fact that the command: @oemit me=Joe says "hi" actually causes everyone else in the room to see the phrase. This bug has been fixed; the above command now causes a permissions error for any user other than Joe. The second example is of a bug with the way @clone worked on the "inherit" flag. The @clone command causes an object to be duplicated, and all its flags are set exactly as they are in the original object. The following sequence of commands, issued by a user with the "modify:yeslt" power, gave that user full Director-level powers. Assume for this example that Robin is a Director, and that Joe, who is not a director but has power "modify:yeslt", walked into a room owned by Robin and not set Inherit, and issued the following commands: @create tmp @va tmp=$*:[v(0)] @set tmp=inherit @drop tmp @force here=@clone tmp The result would have been that a new object would exist named tmp, owned The result would have been by Robin, and with the Inherit flag set. This object would be a power tool (see section III. C. 1., above), and could be used by anyone to perform any director-level command. The bug has been fixed by reprogramming @clone in the server. The @clone command will only set the Inherit flag on a new object if the enactor -- as well as the object to be cloned -- has its Inherit flag set. In the above example, if the room were set Inherit, Joe would not be able to @force the room to @clone the object, and if it were not set Inherit, the new tmp object would not have the Inherit flag set either. These bugs are just two of many discovered in previous versions of the server that have been fixed in the current implementation (version 1.7b4). III. E. Parent Objects When one object inherits attributes from another, the attributes on the former are executed with its own permissions. For the most part, this is what is desired: a user may create a generic widget, and then other people may own child widgets that are controlled by their owners. However, when the inheriting object is an administrator character, or an empowered object owned by an administrator, there are security risks. The owner of the parent object can, by adding new inheritable attributes to the parent object, effectively modify the empowered child object. This modification can be a security risk in one of several ways: (1) The empowered object is in a public place and has no ulock set. In this case, the object can have a new command placed on it, which can then be triggered by anybody at all. For example, if the owner of the parent object types the following: @defattr parent/newattr=inherit @newattr parent=$xxx:@class *Terry=Administrator then the child object will now proceed to class the user Terry to Administrator whenever someone in the vicinity of the object types xxx. (2) The empowered object is a zone object. The same scenario as above applies, except that triggering the newly-created action is now simply a matter of being located somewhere within the zone covered by the zone object. If the empowered object is the Universal Zone Object (UZO) --object #20 on most MUSEs -- then it can be triggered from anywhere on the MUSE by anybody who knows about the new command. Since the UZO is generally an empowered, Director-owned object, it generally has the power to perform all MUSE functions, including the granting of powers and the reclassification of users. (3) Even if the affected child object is not available for general use, there is the danger that the owner will inadvertently trigger a command placed upon it. For example, if a Director character is the child of an object owned by someone else, and the owner of the parent types the following: @defattr parent/newattr=inherit @newattr parent=$mail*:@class *Terry=Administrator then, should the Director ever make a typo while typing +mail, and forget the leading + symbol, he or she will inadvertently class Terry to Administrator. The particular examples discussed above are unlikely to go unnoticed, but they underline the basic point: anyone who owns a child object is subject to exploitation by the owner of the parent. It follows that no users should add themselves or their objects to the children-list of any other unless they trust the owner of the parent. It also follows that, for security reasons, no Director-owned and empowered object should have any parents that are not also owned by Directors; the same is true for all other empowered administrators of a MUSE. Pay attention in particular to the UZO, as that object is most vulnerable to exploitation: all UZO parents (and parents of those parents, and so forth) must be Director-owned. Because of the serious nature of this security problem, it may be time to consider redesigning the way in which the privileges of inherited attributes are handled. I will outline one possible solution in the "Conclusions and Recommendations" section, below. IV. Database Size MUSE databases must fit both into available memory (RAM) and onto a disk file. There is no theoretical limit to the size of a database, but depending on the hardware available, there may be a practical limit beyond with the MUSE should not grow. While there exist MUSE tools to monitor database growth, the only tool available to limit it is largely ineffective; consequently, care must be taken to monitor the database size regularly. The @quota command is generally seen as a method for controlling the size of the database. While it can do so indirectly to a small extent, @quota controls only the number of objects in the database. An object, however, can range in size from approximately 70 bytes up to about 150 Kb. (Directors can create objects of any size at all, but other users can only define a limited number of new attributes on an object, and it is by defining new attributes and filling them with long strings that an object is made to grow.) The mean object size on many MUSEs is about 500 bytes, but a few minutes' of work on the part of an individual with a quota of 20 objects could result in a database size increase of 3,000 Kb (3 Mb), which could result in decreased performance if the dbase size exceeds the RAM size and must be paged out to virtual memory, and which in any event will use up large amounts of disk storage space. In the long term, the server should be modified to permit restrictions on total bytes used by any individual. For the present, MUSE operators must keep a careful eye on the database size, using available monitoring tools such as the "dbinfo" channel, which periodically broadcasts the total size of the database, the playmem() function, which can be used to determine the total memory used by a given user, and the @dbtop memory command, which lists the top 26 memory users. V. Spoofing One type of security hole that is often overlooked as such is the ability to "spoof", that is, to pretend to be someone other than the person you really are. On a MUSE any ability to begin an output line with someone else's name or with the name of a +com channel gives rise to potential spoofing. If I see one of the following lines: Susan says "Hi." Susan whispers "Hi." Susan pages: Hi. [public] Susan: Hi. Susan looks around the room. then I will assume it is the character "Susan" who is talking, whispering, paging, using a +com channel, or posing, respectively. If another user has somehow managed to cause me to see one of the above lines without Susan's knowledge, I will be deceived into believing I am having a conversation with Susan. The consequences may be trivial or serious, but in either case the problem of deception is clear. For this reason, the MUSE server has been written to prevent, as far as possible, any user from beginning an input line with someone else's name. This restriction has the unfortunate side effect of preventing legitimate uses of "spoofing" -- for example, if a cup of coffee is programmed with the following line of code: Va:$drink:@emit %n drinks the coffee the object will not perform as desired; when user Susan types "drink" to activate the object, and the cup attempts to emit the line "Susan drinks the coffee", a spoof-protection violation will occur and the @emit will fail. MUSE operators are of two minds on the issue of spoof-prevention. Some feel that the loss of functionality is too much of a price to pay to prevent spoofing, and that it is really not a big problem. Others feel that the potential for significant deception is a serious enough problem to warrant the action taken by the MUSE designers. Since functionality such as is shown in the previous example can be essential to some projects, the "Spoof" power can be granted to a project or administrator character, enabling that character (and the character's empowered objects) to spoof. Of course, such power must be given only to trusted individuals, but those MUSE operators who take the unrestrictive point of view may wish to trust everyone and give everyone the power. Spoof-protection code in the server currently prevents using @emit or any of its variations (@pemit, @nemit, @remit, @zemit, @oemit, etc.) to output a line beginning with someone else's name, or with someone else's name followed by the "'s" possessive ending; it also prevents users from creating a puppet with someone else's name (the puppet will be set Haven so that it cannot perform commands). There remain several methods of spoofing that cannot be prevented by the MUSE server. For example, there is no restriction on beginning an @emit with the string [public]; therefore, any user can type @emit [public] Susan: Hi. and, possibly, convince the other occupants of the room that Susan has just spoken over the public +com channel. Other more intricate methods are occasionally discovered by some user. Server modifications are made whenever possible to prevent new spoofing methods, but some modifications would cause cumbersome restrictions and cannot reasonably be removed, therefore MUSE administrators must remain aware of the potential problems. All spoofing methods can be detected by use of so-called "spoof detector" objects, but only if they are installed before the fact. If spoofing were to become a major problem, server modifications could be made that would enable users to retrieve, after the fact, the enactor of a recent utterance, but for now such an option is not available. VI. Security from a User's Point of View Although the bulk of security issues are of concern only to MUSE administrators, some aspects of MUSE security should be known to all users. Users should know how to guard their objects from being misplaced or misused, and should be aware of the limitations on their privacy of communication and of how to protect themselves from invasions of privacy. Areas of concern to all users are discussed in this section. VI. A. Locking objects Many users are not aware that an unlocked object can be picked up and moved around by other users. Users should know how to use the @lock command. Those users who are able to create attribute- commands (verbs) should also understand how they are triggered, and should be aware of the @ulock and attribute-lock methods of preventing unauthorized use. VI. B. Parent objects Although this subject was discussed in detail in section III. E., the issue of adding parents to one's objects or one's character is a risk for all users, not just administrators. Users should be aware of the risks; they should add parent objects only when they trust the owner of the parent object implicitly. VI. C. Robots A Robot character, which is a user character owned by another user, controls its owner and all its owner's objects. Users should be made aware of the risks inherent in allowing other individuals access to robots that they own. Users should be held as liable for distributing passwords to their robot characters as they would be if they distributed the password to their own character. VI. D. Privacy Privacy on a MUSE is a serious and difficult issue, and a full discussion is beyond the scope of this paper. The "help privacy" page, distributed with most MUSE servers and written by this author, is available as part of reference [1], but that article is necessarily short. A longer paper on privacy issues, including the legal issues involved, is forthcoming. In the meantime, it would be remiss not to mention the problem at all in a paper dealing with security issues, and this section will discuss some of the problems briefly. Most MUSE users are aware that the System Administrators can examine the objects they have created and added to the database, and although they may expect the administrators to respect their privacy, most understand that, at least on occasion, an administrator may need to examine or modify one of their objects. However, a deeper expectation of privacy exists with respect to online communication; a MUSE, by virtue of its ability to look and feel something like the real world, sets up this expectation. When one character pages another, whispers to another, uses a +com channel on which only certain people are listening, or talks to another character or small group of characters in a private room, or uses the +mail system, the speaker naturally believes that only the intended hearers are listening. This expectation may be violated in one of many ways, but there are methods to protect oneself from most such ways, by using the @sweep command before talking, or by restricting one's discussion to pages or whispers. There are several ways in which privacy may be violated, however, against which the user has no protection; the common thread of these ways is that they are built into the server. There is no way for a user to tell whether the MUSE server is logging what is being typed into the MUSE. In theory, every line of input could be stored in a log file. In fact, most MUSEs do store the last 50 or so executed commands for debugging purposes (to be examined in case of a crash), and these last 50 lines might include a few input lines from users, but rarely enough to establish the context of a conversation. Even so, it is necessary to trust that the administrators of a MUSE would not examine these files regularly, and would be extremely circumspect about any conversation accidentally overheard. More generally, one must trust that the MUSE administrators are not in fact logging and examining all one's conversations. MUSE operators should also be aware of the potential legal ramifications of recording conversational input to the MUSE. It is beyond the scope of this paper to discuss the problem in detail, but in short, the more that is recorded by a MUSE operator, the more likely it is for the operator to be held liable in the event that unlawful activities are discussed or planned online. By default, MUSEs do not record typographical errors (input lines that result in the users' seeing the standard Huh? Type 'help' for help message), but there is a compile-time switch that allows a MUSE to record all such input into a huhlog file, which is then mailed at regular intervals to the owner of the room in which the input line was typed. Although the intent is to provide builders of an area with a record of what sorts of commands users expect to be able to enter, this feature also gives rise to potential privacy violations. Typographical errors often include such things as mistyping the word "page" when sending a private message, yet those would be recorded in the huhlog when such logging is enabled. I recommend that the huhlog option be removed from the distribution version; this should not present a problem, as I do not know of any MUSEs where it is currently used. All +mail sent from one user to another is stored as plain text in the database (mdb) file. It is incumbent upon System Administrators both to prevent the database file from being read by unauthorized users, and to respect users' privacy by not reading it themselves. Perhaps in the future an encryption algorithm could be included in the +mail system to prevent any but the recipient from reading +mail, but such a system is not currently being considered for upcoming versions of the MUSE server. VII. Host Computer Security Two issues must be addressed regarding the security of the host computer on which the MUSE runs. The first concerns the protection of the database file, message files, and log files used by the MUSE; the second concerns the potential for MUSE users to access other areas of the host computer. A MUSE keeps its database in main memory while running, and writes the entire database to disk on a regular basis. If a MUSE crashes and must be restarted, the last saved copy of the database will be reloaded into memory. As with any large, important file, the database file should be backed up frequently, both to other files on disk, in case the primary copy should be corrupted, and to tape or other backup media in case of a disk failure. At the Unix file level, care should be taken that the database and other files are not writeable or readable by unauthorized users of the host computer; anyone with access to the database file can examine the entire virtual world of the MUSE (and change any aspect of it, if they have write-access). The log files created by the MUSE may also contain sensitive information and should be read-protected; in particular, the MUSE logs the account names and passwords given when a new MUSE user is created (although it does not log subsequent changes to the password by the user, and passwords are stored in encrypted form in the database file). For most MUSE owners, there is no risk of individuals with MUSE characters breaking out of the MUSE to run other system programs or use other system resources. The exception is for those MUSE systems that have enabled the @exec command; by default, this command is disabled when a MUSE is compiled. The @exec command allows users with the "Exec" power to run other commands on the host system, under a Unix shell specified in the server code. It is beyond the scope of this paper to discuss in detail the security problems associated with restricted shells, but there are known security risks as well a wealth of information on how to avoid them. A MUSE owner who wants to enable @exec should be thoroughly familiar with these issues, or should seek outside competent advice before proceeding. -------------------------------------------------------------- VIII. Conclusions and Recommendations This paper has provided an overview of the principal security risks that should be carefully considered by operators of Internet-based MUSE servers; in previous sections the most important these risks have been explained detail, and specific recommendations have been presented for precautions that should be taken by MUSE operators. This final section summarizes the specific precautions mentioned throughout the paper, and discusses steps that may be taken in the future to further reduce the risk of security problems. VIII. A. Access Recommendations The trend in Internet-access is moving towards public-access sites, and as a result accountability is becoming increasingly difficult to provide at point of access. Consequently, MUSE operators desiring a reasonably secure level of accountability must provide for it at their own sites by restricting or prohibiting Guest access, and by following proper character registration standards. To restrict Guest access to a site, MUSE operators may choose one of the following courses of action: 1. Modify the MUSE server so that Guest connections are no longer possible. This method is the most secure against unauthorized entry. In a system that encourages new users, the welcome screen message must indicate how to apply for a registered character (see below for recommendations on registration processes). 2. Modify the database so that Guests, when they connect, have their freedom of action restricted (using such devices as the "slave" flag). Then provide Guests with online or offline registration options, or allow them to explore a carefully-constructed Guest area with no exits to the rest of the MUSE database. If there is usually an Administrator online, another option Guests may be provided is the ability to communicate directly with one of the MUSE Administrators. When registering new users, new account names and passwords should never be given out online, since there is no way to verify the identity of the person with whom one is conversing. All passwords should be mailed to an e-mail or U.S. mail address provided by the registrant, or provided by telephone to a home number. These methods ensure that the MUSE operator can later trace the user to a real address or telephone number, but they do not provide perfect accountability. Additional security may be obtained by using only U.S. mail, as e-mail accounts are sometimes borrowed or stolen. Special care should be taken when dealing with e-mail addresses to Freenet sites, on which the use of accounts registered to other people is common. The method by which registration information is collected (whether online or by e-mail) is of less importance than the method by which password information is distributed. Users should be assigned random, non-word passwords, and should be educated about password security, including the need to choose passwords that cannot be guessed using password-cracking programs, and should be strongly cautioned against sharing their passwords with others. Such education is most effective at the time of registration. For added security, MUSE operators may wish to remind users to change their passwords the first time they log in, and again at occasional intervals. Password may also be reset to new random values on occasion and mailed back to the e-mail addresses provided by all characters at registration; this measure helps ensure that registration information is accurate and up to date. VIII. B. Server Operation Recommendations (1) When a MUSE is first installed on a Unix system, two major subdirectories are created: the src directory contains the source code, and the run directory contains the database in the run/db subdirectory, the log files in the run/logs subdirectory, and assorted text files in the run/msgs subdirectory. It is essential for privacy and security that the run/db and run/logs directory be readable only by trusted MUSE administrators. The database file, run/db/mdb, contains not only the full text of every attribute on every object, but also all the private +mail sent between users; in addition, encrypted passwords are stored on each player in a format that, while undecipherable in the general case, leaves easily-guessed passwords vulnerable to dictionary-lookup schemes. For all of these reasons, the database file should be carefully guarded. Some of the log files also contain sensitive information; in particular, the run/logs/sensitive file may contain the plaintext of new passwords, and the run/db/commands and run/db/commands~ files contain a log of the last 50 or so commands executed by the MUSE. While these are intended to be used only by for debugging purposes by system administrators, the potential for privacy violations is clear if they are left open for public reading. (2) Log files are mirrored online on certain +com channels. The most important channel to monitor is *log_sens, as password information for newly-created characters is broadcast to that channel. The channel cannot be added by non-administrators using the standard +channel command, but it is always possible that some user will exploit an unknown bug to join the channel. A quick execution of the command +com *log_sens=who can detect any such listeners, and is recommended before using @pcreate or @newpassword. (3) When setting up a new MUSE database, it is a good idea to reserve the Boss (#1) character as a non-user character, to be employed only for the purpose of creating new Directors, setting the Universal Zone, or performing those other few tasks permitted to Boss alone. The Boss character should not own any objects. (4) Empowered, administrator-owned objects should have as parents only other empowered, administrator-owned objects. This precaution applies to the UZO object, but also to other empowered objects and to the administrator characters themselves. In addition, users should be warned against owning child objects when the parent object belongs to someone they do not trust implicitly. (5) No non-administrator should ever be on the users list of any administrator. MUSE operators should also be aware that if a Group character has powers, then all those on the Group's users list also have the same powers. (6) Because the size of a MUSE database cannot be adequately controlled, it must be regularly and frequently monitored; at least one System Administrator should always be on the dbinfo +com channel online to check on the total size, and should use the @dbtop memory command or the playmem() function to determine individual usage both on a regular basis and in case of sudden unexplained database growth. (7) Procedures should be established to check all newly-created empowered objects as they are created to ensure they are free from "wizbugs". Teams of administrators may wish to work on this project together, as even the best of programmers will occasionally introduce a bug. (8) To protect users' privacy and skirt potential legal problems, do not use the huhlog feature. Turn off the debugging feature that logs the last 50 or so commands if you do not intend to use it. If you do find it necessary or desirable to record and save input to the MUSE, be sure that your users are properly informed. But be aware that the more you record, the more liable you may be in the event that unlawful activities are planned or discussed on your system. VIII. C. Server Modification Suggestions A section on server modifications is likely to become at least partially obsolete shortly after the publication of this paper. Nevertheless, there are many MUSEs already in operation, and System Administrators who do not wish to upgrade to a new distribution version, when one becomes available, may nevertheless wish to implement some of these suggestions on their own MUSEs. Other suggestions may not meet with general approval, or may take a substantial amount of design and programming time, and may never in fact be implemented in a distribution version. (1) Modify the way the %0 (more generally, %x for any x) is handled, so that parentheses are changed to harmless symbols like < and >. (2) Modify the @newpassword and @pcreate commands so they no longer record the passwords as part of the log file entry created when they are executed. (3) Implement a better mechanism for handling database size and individual limits. One such mechanism is to add a bytelimit attribute which can be set by administrators, and which is examined by the @create, @clone, @chown, @open, @dig, and @set commands (and by all the variants of @set) to ensure that the user's total memory usage remains below the limit. (4) Redesign the parent-child paradigm. There are problems associated with any new design; one nice thing about the way MUSEs currently work is that someone who owns a parent object can, by modifying it, fix problems in all the child objects at once, no matter who owns them. However, this same advantage leads to the security risk; the "fix" may be malignant rather than benign. One possible solution is to flag any attributes that have been changed since children were added, so that owners of children must specifically enable them in order for the changes to take effect. Another possibility is to prevent objects with children from being changed except by an administrator. Undoubtedly, other MUSE server designers will develop additional possible solutions. -------------------------------------------------------------- Bibliography [1] MUSE v1.74b distribution version with documentation, available by anonymous ftp from mcmuse.mc.maricopa.edu in the /muse/server directory. [2] MuseMan 1.5c by Edward L. Wallace (Falryx), available by anonymous ftp from chezmoto.ai.mit.edu in the /muse/docs directory. -------------------------------------------------------------- Acknowledgements This paper was written under a contract with the Maricopa County Community College District in Arizona, with the support of Professors Jim Walters and Billie Hughes of Phoenix College and MariMUSE.