Last revised: September 24, 1997
Updated copyright statement
A complete revision history is at the end of this file.
Many sites that maintain a Web server support CGI programs. Often these programs are scripts that are run by general-purpose interpreters, such as /bin/sh or PERL. If the interpreters are located in the CGI bin directory along with the associated scripts, intruders can access the interpreters directly and arrange to execute arbitrary commands on the Web server system. This problem has been widely discussed in several forums. Unfortunately, some sites have not corrected it.
The CERT Coordination Center recommends that you never put interpreters in a Web server's CGI bin directory.
We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site.
I. Description
To execute CGI scripts, a Web server must be able to access the interpreter used for that script. Early documentation for Netscape and other servers recommended placing the interpreters in the CGI bin directory to ensure that they were available to run the script.
All programs in the CGI bin directory can be executed with arbitrary arguments, so it is important to carefully design the programs to permit only the intended actions regardless of what arguments are used. This is difficult enough in general, but is a special problem for general-purpose interpreters since they are designed to execute arbitrary programs based on their arguments. *All* programs in the CGI bin directory must be evaluated carefully, even relatively limited programs such as gnu-tar and find.
Note that the directory for CGI programs is typically called "cgi-bin" but the server may be configured to use a different name.
II. Impact
If general-purpose interpreters are accessible in a Web server's CGI bin directory, then a remote user can execute any command the interpreters can execute on that server.
III. Solution
The solution to this problem is to ensure that the CGI bin directory does not include any general-purpose interpreters, for example
- PERL
Tcl
UNIX shells (sh, csh, ksh, etc.)
On Unix systems, the location of the interpreter is given on the first line of the script:
- #! /path/to/interpreter
On other systems, such as NT, there is an association between filename extensions and the applications used to run them. If your Web server uses this association, you can give CGI scripts an appropriate suffix (for example, ".pl" for PERL), which is registered to the appropriate interpreter. This avoids the need to install the interpreter in the CGI bin directory, thus avoiding the problem.
Check with your Web server vendor for specific information.
Netscape reports that the 2.0 versions of their FastTrack and Enterprise Servers, (both the current Beta and upcoming final versions), do support file interpreter associations.
Further reading:
Tom Christiansen has a Web page with details about this problem and a script that can be used to test for it:
http://perl.com/perl/news/latro-announce.html
Lincoln Stein's WWW Security FAQ includes a section on "Problems with Specific Servers," which discusses this and related problems:
http://www.genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The CERT Coordination Center thanks Lincoln Stein, Tom Christiansen, and the members of AUSCERT and DFN-CERT for their contributions to the information in this advisory.
Copyright 1996 Carnegie Mellon University.
Revision History
Sep. 24, 1997 Updated copyright statement Aug. 30, 1996 Removed references to CA-96.11.README.