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.
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:
-
Only one "word" is allowed in the command tail.
-
No pipe chars, or greater than or less than, or semicolons are allowed.
-
No absolute directories are allowed. Command tails starting with a slash
are squelched.
-
Only one .. (up directory) is allowed. That .. is intended
to move you from the cgi-bin directory to the main directory. From there
you can move down, but not out to directories not belonging to you. Note
that if your ISP allows you to execute CGI in any directory, or in your
top directory, you should disallow .. completely.
-
Command buttons use commands which read but do not write. You should not
modify any file you cannot write or chmod with FTP.
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!