|
|
| Previous | Table of Contents | Next |
The WWW server can be configured to change its root file system to a controlled file system, or the chroot command can be used on startup for the same effect. This is a very effective preventative measure against cracking. If the server does not have a chroot configuration option, the command would look something like this:
% chroot /www /www/bin/webserver
This would set the new root file system for the httpd process to /www. Only files under the /www file system could be accessed.
When you run chrooted, the server (and by extension any CGIs) has access only to those external programs present in the new file system. Attempts to break the security of the server and CGIs are hampered by the absence of shells, powerful command interpreters, and the like.
Of course, this severely limits the options for writing CGIs. For example, to run a PERL or shell script, a PERL interpreter or shell must be made available in the chrooted file system, which undermines its effectiveness. This can also be an administrative headache for a number of reasons: users cannot serve files from their home directories (unless the directories are under the chrooted area); shared libraries cannot be used unless copied in; and so on. Statically linked C or C++ binaries can be run without ill effect—this is the best way to utilize chroot.
The fewer tools available to the server and CGI processes, the harder it is to compromise the machine. Running the server chrooted helps accomplish this, but on many Unix machines it is possible to escape from a chrooted area.
This machine should be locked down as tightly as possible. A CGI weakness will most likely provide the cracker with an unprivileged shell, so make it as difficult as possible to turn this into a root shell.
Recall that CGIs normally all run under the same unprivileged UID.
Nathan Neulinger has written a utility called CGIWrap (http://www.umr.edu/~cgiwrap/) that runs CGIs under the UID of the owner of the program. It can be used with any server; it acts only as a wrapper for the actual programs. Each user has a dedicated CGI directory.
CGIWrap takes several security precautions before executing anything. For example, it does not execute SUID programs or follow symbolic links out of a user’s script directory. It can be used to automatically limit the resources a CGI consumes, and it also provides a number of convenient debugging options.
If multiple users want to run CGIs on the same machine, running them all as the same UID might be ill-advised. Any user could write a CGI to read and write any other files owned by the server UID. In an environment where the users do not have common cause, such as an Internet service provider, this is unacceptable. CGIWrap solves this problem, enabling each user to maintain their own set of files for CGI programs.
The primary downside is that a user’s personal files are potentially vulnerable to a CGI security hole. For example, a CGI that accidentally allowed remote users to execute shell commands could easily be harnessed to remove a user’s entire home directory. If CGIWrap is used, all users should be clearly warned to write their programs with great care.
A possible way to help alleviate this problem is to assign users a second UID to be used only for CGI work. This provides separation between users without exposing a user’s regular files to attack.
This does carry additional administrative overhead. CGIWrap must be run SUID-root so it can assume the proper privileges before executing programs. Fortunately, it is relatively short, and a prudent administrator can review the source before installing. As with all SUID-root programs, this is recommended.
If the number of CGI programs that need to be run by the server is relatively small, it is worth considering disabling CGI entirely and integrating the programs into the server directly. This has the added benefit of increased efficiency because no additional forking is necessary to handle the requests. For example, the widely used imagemap capability, once available only as a CGI, is now built into many servers.
The steps required to integrate programs into the server are highly server- and language-specific and are not for the faint of heart. Some servers might support the addition of modules more explicitly in the future.
The efficiency gains diminish rapidly if a great deal of code is added to the server, because the size of the server process grows and the overhead in regular forking increases. If the server must provide a wide variety of services normally provided by CGI, or be easily and quickly extensible, this is probably not the best option.
Server Side Includes (SSI) do not use the Common Gateway Interface but are used for similar purpose. In fact, anything accomplished via SSI could be done with CGIs. An SSI document is parsed by the server before being sent to the client, and the server can take various actions based on the directives contained therein. SSI can be used to include other documents, output current documentation, or—most worrisome—to execute shell commands.
Server parsing of the document carries quite a lot of overhead, and it is usually unnecessary. On that basis alone, Web administrators should explore other avenues.
Allowing unrestricted access to SSI is equivalent to unrestricted access to CGI and should be treated with the same level of skepticism. The server configuration should allow specification of the directories in which SSI is allowed.
Only files with a designated file extension can be parsed by the server; often .shtml is used for this purpose. Overly helpful server documentation might indicate that you can use .html if you don’t care about the overhead of parsing all files. Do not do this! SSI is a powerful interface that should not be enabled in all documents by default.
The server might allow documents to include static documents but preclude it from using the EXEC command to execute shell commands. If this option is available, use it whenever possible. Especially be sure to disable the execution of commands from directories that run CGI programs. CGIs often generate dynamic documents based on user input. One of the biggest dangers of SSI is that through a configuration error, a user will be able to submit SSI commands and compromise security. Consider the consequences if a cracker submitted a form containing the following text:
<!--#exec cmd=”/usr/bin/cat /etc/passwd” -->
and the resulting document were server-side parsed.
| Previous | Table of Contents | Next |