****************************************************************************** ------ ----- ----- --- ----- | ----- ---- | | | | | |--- | | | | | | | | | |-- | | | | |-- | | | | | | | | \ | | ----- ---- ----- ----- | \ ----- A D V I S O R Y FA-97.80 ****************************************************************************** Topic:CGI scripts Vulnerability REVISED - Code Correction Source:CERT/CC Creation Date: 11/10/97 Last Updated: 11/12/97 To aid in the wide distribution of essential security information, FedCIRC is forwarding the following information from Cert Advisory CA-97.25. FedCIRC urges you to act on this information as soon as possible. If you have any questions, please contact FedCIRC: Telephone: +1 888 282 0870 Email: fedcirc@fedcirc.gov =======================FORWARDED TEXT STARTS HERE============================ -----BEGIN PGP SIGNED MESSAGE----- CERT* Advisory CA-97.25.CGI_metachar Original issue date: Nov. 10, 1997 Last revised: November 12, 1997 Updated the Appendix to fix coding error. A complete revision history is at the end of this file. Topic: Sanitizing User-Supplied Data in CGI Scripts - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports and seen mailing list discussions of a problem with some CGI scripts, which allow an attacker to execute arbitrary commands on a WWW server under the effective user-id of the server process. The problem lies in how the scripts are written, NOT in the scripting languages themselves. The CERT/CC team urges you to check all CGI scripts that are available via the World Wide Web services at your site and ensure that they sanitize user-supplied data. We have written a tech tip on how to do this (see Section III). We will update the tech tip (rather than this advisory) if we receive additional information. - ----------------------------------------------------------------------------- I. Description Some CGI scripts have a problem that allows an attacker to execute arbitrary commands on a WWW server under the effective user-id of the server process. The cause of the problem is not the CGI scripting language (such as Perl and C). Rather, the problem lies in how an individual writes his or her script. In many cases, the author of the script has not sufficiently sanitized user-supplied input. II. Impact If user-supplied data is not sufficiently sanitized, local and remote users may be able to execute arbitrary commands on the HTTP server with the privileges of the httpd daemon. They may then be able to compromise the HTTP server and under certain configurations gain privileged access. III. Solution We strongly encourage you to review all CGI scripts that are available via WWW services at your site. You should ensure that these scripts sufficiently sanitize user-supplied data. We recommend carrying out this review on a regular basis and whenever new scripts are made available. For advice about what to look for and how to address the problem, see our tech tip on meta-characters in CGI scripts, available from ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters We have placed a revised version of this tech tip (dated November 12, 1997) in the appendix of this advisory for your convenience. Any future updates will be made to the tech tip, so please check the electronic version for the most current information. If you believe that a script does not sufficiently sanitize user-supplied data then we encourage you to disable the script and consult the script author for a patch. If the script author is unable to supply a patched version, sites with sufficient expertise may wish to patch the script themselves, adapting the material in our tech tip to meet whatever specification is required (such as the appropriate RFC). (NOTE: We cannot offer any further assistance on source code patching than that given in the tech tip mentioned above.) ............................................................................. Appendix - Tech Tip on CGI Metacharacters (version 1.2, Nov. 12, 1997) The tech tip below may be updated in the future. For the most current version, see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters How To Remove Meta-characters From User-Supplied Data In CGI Scripts 1. Definition of the Problem We have noticed several reports to us and to public mailing lists about CGI scripts that allow an attacker to execute arbitrary commands on a WWW server under the effective user-id of the server process. In many of these cases, the author of the script has not sufficiently sanitized user-supplied input. 2. Definition of "Sanitize" Consider an example where a CGI script accepts user-supplied data. In practice, this data may come from any number of sources of user-supplied data; but for this example, we will say that the data is taken from an environment variable $QUERY_STRING. The manner in which data was inserted into the variable is not important - the important point here is that the programmer needs to gain control over the contents of the data in $QUERY_STRING before further processing can occur. The act of gaining this control is called "sanitizing" the data. 3. A Common But Inadvisable Approach A script writer who is aware of the need to sanitize data may decide to remove a number of well-known meta-characters from the script and replace them with underscores. A common but inadvisable way to do this is by removing particular characters. For instance, in Perl: #!/usr/local/bin/perl $user_data = $ENV{'QUERY_STRING'}; # Get the data print "$user_data\n"; $user_data =~ s/[\/ ;\[\]\<\>&\t]/_/g; # Remove bad characters. WRONG! print "$user_data\n"; exit(0); In C: #include #include #include int main(int argc, char *argv[], char **envp) { static char bad_chars[] = "/ ;[]<>&\t"; char * user_data; /* our pointer to the environment string */ char * cp; /* cursor into example string */ /* Get the data */ user_data = getenv("QUERY_STRING"); printf("%s\n", user_data); /* Remove bad characters. WRONG! */ for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */) *cp = '_'; printf("%s\n", user_data); exit(0); } In this method, the programmer determines which characters should NOT be present in the user-supplied data and removes them. The problem with this approach is that it requires the programmer to predict all possible inputs. If the user uses input not predicted by the programmer, then there is the possibility that the script may be used in a manner not intended by the programmer. 4. A Recommended Approach A better approach is to define a list of acceptable characters and replace any character that is NOT acceptable with an underscore. The list of valid input values is typically a predictable, well-defined set of manageable size. For example, consider the tcp_wrappers package written by Wietse Venema. In the percent_x.c module, Wietse has defined the following: char *percent_x(...) { {...} static char ok_chars[] = "1234567890!@%-_=+:,./\ abcdefghijklmnopqrstuvwxyz\ ABCDEFGHIJKLMNOPQRSTUVWXYZ"; {...} for (cp = expansion; *(cp += strspn(cp, ok_chars)); /* */ ) *cp = '_'; {...} The benefit of this approach is that the programmer is certain that whatever string is returned, it contains only characters now under his or her control. This approach contrasts with the approach we discussed earlier. In the earlier approach, which we do not recommend, the programmer must ensure that he or she traps all characters that are unacceptable, leaving no margin for error. In the recommended approach, the programmer errs on the side of caution and only needs to ensure that acceptable characters are identified; thus the programmer can be less concerned about what characters an attacker may try in an attempt to bypass security checks. Building on this philosophy, the Perl program we presented above could be thus sanitized to contain ONLY those characters allowed. For example: #!/usr/cert/bin/perl $_ = $user_data = $ENV{'QUERY_STRING'}; # Get the data print "$user_data\n"; $OK_CHARS='-a-zA-Z0-9_.@'; # A restrictive list, which # should be modified to match # an appropriate RFC, for example. s/[^$OK_CHARS]/_/go; $user_data = $_; print "$user_data\n"; exit(0); Likewise, the same updated example in C: #include #include #include int main(int argc, char *argv[], char **envp) { static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\ ABCDEFGHIJKLMNOPQRSTUVWXYZ\ 1234567890_-.@"; char * user_data; /* our pointer to the environment string */ char * cp; /* cursor into example string */ user_data = getenv("QUERY_STRING"); printf("%s\n", user_data); for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */) *cp = '_'; printf("%s\n", user_data); exit(0); } 5. Recommendation We strongly encourage you to review all CGI scripts available via your web server to ensure that any user-supplied data is sanitized using the approach described in Section 4, adapting the example to meet whatever specification you are using (such as the appropriate RFC). 6. Additional Tips The following comments appeared in CERT Advisory CA-97.12 "Vulnerability in webdist.cgi" and AUSCERT Advisory AA-97.14, "SGI IRIX webdist.cgi Vulnerability." We strongly encourage all sites should consider taking this opportunity to examine their entire httpd configuration. In particular, all CGI programs that are not required should be removed, and all those remaining should be examined for possible security vulnerabilities. It is also important to ensure that all child processes of httpd are running as a non-privileged user. This is often a configurable option. See the documentation for your httpd distribution for more details. Numerous resources relating to WWW security are available. The following pages may provide a useful starting point. They include links describing general WWW security, secure httpd setup, and secure CGI programming. The World Wide Web Security FAQ: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The following book contains useful information including sections on secure programming techniques. _Practical Unix & Internet Security_, Simson Garfinkel and Gene Spafford, 2nd edition, O'Reilly and Associates, 1996. Please note that the CERT/CC and AUSCERT do not endorse the URL that appears above. If you have any problem with the sites, please contact the site administrator. Another resource that sites can consider is the CGI.pm module. Details about this module are available from: http://www.genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html This module provides mechanisms for creating forms and other web-based applications. Be aware, however, that it does not absolve the programmer from the safe-coding responsibilities discussed above. Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. CERT is registered in the U.S. Patent and Trademark Office. This file: ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters Last revised November 12, 1997 Version 1.2 - ----------------------------------------------------------------------------- The CERT Coordination Center thanks Wietse Venema for some of the material used in the cgi_metacharacters tech tip. We thank Mark Mills for his communication with us about the bug in the appendix and acknowledge Andrew McNaughton and Greg Bacon, who pointed out the bug on bugtraq. - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/). CERT/CC Contact Information - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://ftp.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. *CERT is registered in the U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metachar http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history Nov. 12, 1997 Updated the Appendix to fix coding error. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNGnWynVP+x0t4w7BAQFgHQQAnwHRMZJGA7SuFNE2Vt6QAR143ChExpAb KA7xBJhVYzAH7AnLc39SbA3PeDaj2kf7bfhZQHJc8SNsHRIKC6jciVHvvKmHbN5C 45mDEqfSN3OOYvD3kVsVYrG8X9KM9QfNfZZFnxx19l5PGo8y0iVYTl5AxNOadLCP oQMg76/n8W8= =TbZo -----END PGP SIGNATURE----- ========================FORWARDED TEXT ENDS HERE============================= The National Institute of Standards and Technology (NIST) has established a Federal Computer Incident response Capability (FedCIRC) to assist federal civilians agencies in their incident handling efforts by providing proactive and reactive computer security related services. FedCIRC is a partnership among NIST, the Computer Incident Advisory Capability (CIAC), and the CERT* Coordination Center (CERT/CC). If you believe that your system has been compromised, please contact FedCIRC: Telephone: +1 888 282 0870 Email: fedcirc@fedcirc.gov Web Server: http://www.fedcirc.gov/ * Registered in U.S. Patent and Trademark Office The CERT Coordination Center is part of the Software Engineering Institute. The Software Engineering Institute is sponsored by the U.S. Department of Defense. CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.