Executing Shell Scripts Inside Mosaic

A frequent request of Mosaic users is to have hyperlinks cause local -- client-side -- processes (i.e., shell scripts, which may call other programs) to be executed.

One scenario where this would be useful is in a local client/server environment, where Mosaic is used as a front end to a number of other applications -- a document could explain what various applications do, and hyperlinks would cause the applications to be launched on the local machine.

As of Mosaic 2.0 prerelease 4, this is now possible. This opens up a number of questions and security concerns, and this document attempts to address both.

OK, How's It Work?

Consider what happens if the following takes place:

An entry is placed in the user or system mailcap that looks like this:
```
        application/x-csh; csh -f %s
```
The client then accesses a document on a local or remote HTTP server that is typed application/x-csh. (Or, an entry could be placed in a user or system extension map to associate extension .csh with type application/x-csh, and a document foo.csh could be accessed on the local filesystem or on an FTP server.)

Obviously, csh -f will be used as the "viewer" for the document, which means the shell script -- whatever it happens to contain -- will be executed on the client's host.

As an example, if you have the above mailcap entry in place, the following hyperlink will start up /usr/bin/X11/xclock on your host:

Security Implications

Since Mosaic is not shipped with support for application/x-csh or anything similar in the default settings, this is not a security hole unless you specifically modify your config files to make it so.

However, as soon as you add the entry for application/x-csh as above to your user or system mailcap, you have a security hole. A malicious information provider (anyone running a server) could construct a dangerous shell script referenced by an innocuous hyperlink in one of his/her documents, and you could click on it and cause it to be fired off on your system without realizing what's going on.

Dealing With the Security Implications

One way to deal with the security hole this raises is to make the choice of whether or not a given shell script is actually executed something the user gets to decide on a per-script basis. This can be done by using a small utility program as the "viewer" for application/x-csh (and similar) documents; the utility program will do the following:
- Accept a filename as a command-line argument.
- Read from disk and display that file (being careful to ensure that the user actually sees what's in the file).
- Ask the user, "Do you want to execute this?" and present "Yes" and "No" buttons.
- Execute the shell script by forking csh if the user selects "Yes".
Such a program doesn't exist yet; we may write it. (The assumption does exist, however, that the user is qualified to judge on the fly whether a given shell script is safe to run.)
Note: The following shell script, safecsh, is one possibility; it uses a semi-standard X utility called xmessage to display any encountered csh scripts and query the user.
```
#!/bin/csh -f
xmessage -buttons "Execute this file,Cancel" -file $1
if ($status == 101) then
	csh -f $1
endif
```
Thanks to friendly user Michael Frank for the suggestion.
Another way to deal with the security hole is to use a made up MIME type (e.g., foobar/236454531154) as the signifier for a shell script on both the client and server side. This means that your client will not execute shell scripts on other sites of type application/x-csh or anything similar, but will execute shell scripts coming off your own server as your special type.
But, were a person with malice in his/her heart to take a close look at your server and see that it's serving shell scripts as type foobar/236454531154, he/she could then construct a bomb on his/her server by using exactly that type, and you could get hit while browsing the net. The only way to get around this is to prohibit off-site accesses (or use some even tighter method of control). We are adding such capabilities to NCSA httpd, and other servers may either already have or will soon have such capabilities.
Possibly the only really safe way to deal with the security hole is to tightly restrict how Mosaic clients configured to handle application/x-csh and the like are used. If Mosaic in such a state is only used to access local, approved files that are known to be safe, then you won't get your filesystem nuked just by browsing the net. (Maybe make a shell script, e.g. xdangerousmosaic, that fires up Mosaic with a different globalTypeMap resource setting, to make this explicit.)

Comments or Questions?

Mail mosaic-x@ncsa.uiuc.edu.