-----BEGIN PGP SIGNED MESSAGE-----


===========================================================================
             AUSCERT External Security Bulletin Redistribution

                             
                   ESB-97.147 -- CERT Advisory CA-97.25
               Sanitizing User-Supplied Data in CGI Scripts
                             11 November 1997

===========================================================================

	Since the original release of this External Security Bulletin on
	11 November 1997, CERT Advisory CA-97.25 has been updated.  The
	contents of ESB-97.147 have been modified to reflect those changes.

	The latest version of CA-97.25 can be retrieved from:
		 
            ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metachar

===========================================================================

The CERT Coordination Centre has released the following advisory discussing
problems with some CGI scripts.  These problems may allow an attacker to
execute arbitrary commands on the HTTP server with the privileges of the
the httpd daemon.  This can be leveraged to compromise the HTTP server
and, under certain configurations, gain privileged access.

The following security bulletin is provided as a service to AUSCERT's
members.  As AUSCERT did not write this document, AUSCERT has had no
control over its content.  As such, the decision to use any or all of this
information is the responsibility of each user or organisation, and should
be done so in accordance with site policies and procedures.

Contact information for CERT/CC is included in the Security Bulletin below.
If you have any questions or need further information, please contact them
directly.

Previous advisories and external security bulletins can be retrieved from:

	http://www.auscert.org.au/information/advisories.html

If you believe that your system has been compromised, contact AUSCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
	AUSCERT personnel answer during Queensland business hours
	which are GMT+10:00 (AEST).
	On call after hours for emergencies.


- --------------------------BEGIN INCLUDED TEXT--------------------


- -----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
";
        $user_data =~ s/[/ ;[]<>&	]/_/g;  # Remove bad characters. WRONG!
        print "$user_data
";
        exit(0);

In C:

        #include <stdio.h>
        #include <string.h>
        #include <stdlib.h>

        int
        main(int argc, char *argv[], char **envp)
        {
            static char bad_chars[] = "/ ;[]<>&	";

            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
", user_data);

            /* Remove bad characters. WRONG! */
            for (cp = user_data; *(cp += strcspn(cp, bad_chars)); /* */)
                *cp = '_';
            printf("%s
", 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
";
        $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
";
        exit(0);

Likewise, the same updated example in C:

        #include <stdio.h>
        #include <string.h>
        #include <stdlib.h>

        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
", user_data);
            for (cp = user_data; *(cp += strspn(cp, ok_chars)); /* */)
                *cp = '_';
            printf("%s
", 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

iQCVAwUBNGnIPXVP+x0t4w7BAQENxwQAsqsN4gHQBY11IvAmEEXQ94wPiWESRFYc
W3BgUc22qcJnhSlJNuM8bVAismM0+eZLdp5hdRA/rvheJoxXbc2ULGGhNJz4KmJD
tx6/yq66hlttMMUfOidvB+VEaArf//VRoH4XBc4m2hE+iXaM+tlRqzSlz3VOWN+T
SOt1ElkhOEQ=
=VYfA
- -----END PGP SIGNATURE-----


- --------------------------END INCLUDED TEXT--------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBNHBkxSh9+71yA2DNAQEtDwP/dJeKsjgkl1cmrzd/YmfH9ovrSNcG0+Od
61SJhRI0IxWJa6f7vFv/T/n15zy9hjcrDbcN1l+OjZlWuGCS2fzheZI/SKx+tmei
7Sr6FNpQj17FUnjH1rSo2yX9WOZmaqmhTgmpgXii0dPqhDbhwaaL8Whj5cdZcAvg
+t3XQei2cyg=
=xV+7
-----END PGP SIGNATURE-----