About
Community
Bad Ideas
Drugs
Ego
Erotica
Fringe
Society
Technology
Hack
Introduction to Hacking
Hack Attack
Hacker Zines
Hacking LANs, WANs, Networks, & Outdials
Magnetic Stripes and Other Data Formats
Software Cracking
Understanding the Internet
Legalities of Hacking
Word Lists
register | bbs | search | rss | faq | about
meet up | add to del.icio.us | digg it

Common Gateway Interface (CGI) Security, Part 6


NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.






Subject: CGI security vulnerability: %0A (newlines) in user-supplied data


HTML version by Markus H?bner

When sending user-supplied data to a shell in a CGI program, it has
become common practice among security-conscious CGI authors to
remove or escape certain shell metacharacters to avoid them being
interpreted by the shell and possibly allowing the user to execute
arbitrary commands at his or her will.

There are a good set of security guidelines at:
http://www.cerf.net/~paulp/cgi-security/safe-cgi.txt:

That document recommends removing or escaping the following
characters in user-supplied data before passing it to a shell:

;*|`&$!#()[]{}:'"/

There is (at least) one character missing from this list: the new line
character. I have never seen the new line character included in a list
of metacharaters to filter.

A sampling of widely-available CGI programs turned up many that
are vulnerable. Just about any CGI program which "un-hexifies"
(converts characters represented by their hex values in a URL by to
their actual character) its input and passes that input to a shell is
likely to be vulnerable.

Here's a toy example:

#!/usr/local/bin/perl
# usage: http://your.host/cgi-bin/echo?
# Echos back the QUERY_STRING to the user.

$| = 1;
$in = $ENV{'QUERY_STRING'};
$in =~ s/%(..)/pack("c",hex($1))/ge;

# Escape the nasty metacharacters
# (List courtesy of http://www.cerf.net/~paulp/cgi-security/safe-cgi.txt)
$in =~ s/([;\*\|`&\$!#\(\)\[\]\{\}:'"])/\\$1/g;

print "Content-type: text/html\n\n";
system("/bin/echo $in");

Install this program in cgi-bin/echo and

http://your.host/cgi-bin/echo?hello%20there

will return a page containing the text

"hello there"

Insert %0A, the newline character, and you can exploit the shell to
run any command you wish.

For example, the URL

http://your.host/cgi-bin/echo?%0Acat%20/etc/passwd

will get you the password file.

(In Perl, the call to system() should have broken up the arguments:

system("/bin/echo", $in);

and the problem would disappear.)

While this example uses system() in Perl, the general program will
show up whenever a shell is invoked.

THE FIX:

Very simple. Add the character \n (the new line character) to the list
of characters to REMOVE from user-supplied data before suppling
it to a shell in a CGI program.

#!/usr/local/bin/perl
# usage: http://your.host/cgi-bin/safe-echo?
# Echos back the QUERY_STRING to the user.

$| = 1;
$in = $ENV{'QUERY_STRING'};
$in =~ s/%(..)/pack("c",hex($1))/ge;

# Escape the nasty metacharacters
# (List courtesy of http://www.cerf.net/~paulp/cgi-security/safe-cgi.txt)
$in =~ s/([;\*\|`&\$!#\(\)\[\]\{\}:'"\n])/\\$1/g;

# SECURITY FIX: REMOVE NEWLINES
$in =~ tr/\n//d;

print "Content-type: text/html\n\n";
system("/bin/echo $in");

Again, this bug exists in MANY CGI programs. If you maintain
CGI programs on your server, I suggest you check through each of
them. I've only looked through several CGI programs, and found the
bug on some of them (the authors have been contacted). If I have
more time in the near future, I'll post a list of vulnerable programs
as well as alerting the authors. In the meantime, you should check
through the source of all of your CGI programs for this
vulnerability.
 
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.

 

totse.com certificate signatures
 
 
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
Hot Topics
Php
Withstanding an EMP
Good computer destroyer?
Wow, I never thought the navy would be so obvious.
Alternatives Internets to HTTP
Anti-Virus
a way to monitor someones AIM conversation
VERY simple question: browser history
 
Sponsored Links
 
Ads presented by the
AdBrite Ad Network

 

TSHIRT HELL T-SHIRTS