Troubleshooters.Com Presents

July 1999 Troubleshooting Professional Magazine: Troubleshooting CGI

Copyright (C) 1999 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

<--Due Diligence: Do It On Your Linux Box First   |  Contents   |   The CGI Troubleshooting Toolkit-->

Security Considerations

By Steve Litt
Telnet is not the only security consideration. Web access to shell commands also can compromise security. Consider, for instance, a simple form that acts as a command line. This will let anybody with access to the web page perform any command which the httpd user (probably user nobody) is capable. For instance:
cat /etc/passwd
Do you think that capability might be problematic if accessible to a cracker? Note that this command will succeed for user nobody on a typical default Linux server. How bout this:
rm *
If, in your haste via telnet, you have created a directory and files with mode 777, any visitor can delete your files via your html command line form.

The remainder of this article discusses some security musts for your CGI troubleshooting tools.

Put them off the beaten track, and erase them when you're done

Depending on how you code these tools, a cracker can use them to observe anything on the server, even those areas belonging to other users. Make sure the existance of your troubleshooting tools is not known generally, and make sure to erase them as soon as the problem is solved.

Hard code as much as possible

All those reusabilities so elegant in secure environments are the kiss of death on the net. For instance, the ultimate in reusability would be to allow the user to type the entire command. Of course, if somehow /etc/passwd were mode 777, the user could erase it, and maybe replace it with one of his own making if the /etc directory were writable for all. If he does that, he owns the server. Even if he can't do that, he can view the passwd file, or he can look at other user's data, much of which may be proprietary.

The proper way to do it is to offer specific commands, such as ls, which, pwd, whoami, etc. In every case steps should be taken to prevent the cracker from subverting the command. For instance, if one hard-wired command were ls, but there was a field in which to write the command tail, a cracker could get a list of all users with this command tail:

/etc/passwd | xargs cat
There are probably ten other ways he could do the same thing, including
;cat /etc/passwd
So you'll see that most of the tools force you to hard-code the CGI to be run or the files to be investigated. The cmdr.cgi script is an exception, but you'll note several security measures designed to prevent exploits like those above:
  I have provided these CGI Troubleshooting Tools in good faith, on the assumption you will use them for good and not evil, and assuming you will use them intelligently and prudently. I am not responsible for the outcome -- you are. BE ABSOLUTELY SURE to get the approval of the sysadmin before using these tools. DO NOT disable the security features of these scripts. When in doubt, hard code. Always keep the existance and whereabouts of these scripts secret, and delete them when the problem has been solved.

Never chmod anything 777, unless it's a file needing to be written by a CGI script. Any file chmodded 777 can be erased or modified without your knowledge. If a CGI script is surreptitiosly written to your directory, it allows a much wider range of exploits.

Any exploits resulting from your misuse or negligent use of these tools will probably result in revocation of your CGI priveleges, and could lead to your incurring a financial liability. Use these tools for troubleshooting and nothing else, and use them intelligently!

Steve Litt can be reached at Steve Litt's email address.