http-request_method.txt

`Date: Wed, 6 Jan 1999 13:16:07 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
Subject: HTTP REQUEST_METHOD flaw  
  
  
There is a "feature" inherent in some web servers, such as Apache 1.3.x or  
MS IIS, that carries mild security implications that could allow web server  
attacks to go unnoticed.  
  
The problem relates to "allowable" REQUEST_METHODs when a dynamic resource,  
such as a CGI script is requested. Essentially _any_ (except for HEAD,  
TRACE and OPTIONS) REQUEST_METHOD can be used - even methods not defined in  
the HTTP protocol. Consider the following requests which all return the  
requested resource.  
  
GET /cgi-bin/environ.cgi HTTP/0.9  
  
Azx5T8uHTRuDL /cgi-bin/environ.cgi HTTP/1.0  
  
Even Control characters are allowed. Consider the following:  
  
^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1  
  
An attacker could issue this request in an attempt to hide their movements.  
When this request is logged in the access log and viewed using cat or more  
the above will appear with the IP address removed.  
  
# cat /var/log/httpd/access_log  
  
or  
  
# more /var/log/httpd/access_log  
  
reveals  
  
10.20.20.1 - - [05/Jan/1999:18:00:00 GMT] "GET / HTTP/1.0" 200 1098  
/cgi-bin/environ.cgi HTTP/1.1" 200 2034  
10.20.20.2 -- [05/Jan/1999:18:01:00 GMT] "GET /index.html HTTP/0.9" 200 1098  
  
Using a method similar to this it is possible for an attacker to make it  
appear as if the attack came from another IP address or completely remove  
the whole entry by placing certain control characters in the QUERY_STRING,  
too. This "hiding" works because the control characters are interpreted when  
piped to STDOUT and the ^H being the back space removes, from the screen at  
least, the IP address and date and time stamp. You could use the vi editor  
the view the "real" contents of the access log.  
  
This was tested on Apache 1.3.3 on RedHat 5.2 and Apache 1.2.7 on RedHat  
5.0. Also affected is Microsoft's Internet Information Server 2, 3 and 4 but  
in the NT environment this is less of a problem because the log files are  
generally viewd in Notepad and not using the "type" command, which  
incidently will interpret the control characters.  
  
As I said it's only a mild problem most likely, really, to effect those that  
don't use a text editor to browse log files.  
  
Cheers,  
David Litchfield  
  
----------------------------------------------------------------------------  
  
Date: Fri, 8 Jan 1999 03:19:23 +0100  
From: Henrik Nordstrom <[email protected]>  
To: [email protected]  
Subject: Re: HTTP REQUEST_METHOD flaw  
  
Sevo Stille wrote:  
  
> > Even Control characters are allowed. Consider the following:  
> >  
> > ^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1  
> >  
>  
> Of course control chars are and must be allowed - CGI is defined to be  
> transparent towards the application. For a request satisfied by the  
> server, the server would have to (and at any rate apache does) return a  
> 501 method not implemented error, according to the specs, par. 5.1.1.  
1  
  
Not really. RFC 2068 defines method as a token, which is "1*<any CHAR  
except CTLs or tspecials>" so the above may be rejected with a "400 Bad  
Request" reply as it is not valid HTTP syntax.  
  
HTTP puts restrictions on wich characters that are allowable in all  
parts of the protocol except the message body.  
  
---  
Henrik Nordstrom  
  
----------------------------------------------------------------------------  
  
Date: Thu, 7 Jan 1999 14:50:45 -0500  
From: Christopher Masto <[email protected]>  
To: [email protected]  
Subject: Re: HTTP REQUEST_METHOD flaw  
  
  
On Wed, Jan 06, 1999 at 09:30:43PM +0100, Sevo Stille wrote:  
> > Even Control characters are allowed. Consider the following:  
> >  
> > ^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1  
> >  
>  
[...]  
> Quite so. Nonetheless it would be desirable if the common CGI libraries  
> would perform a somewhat more strict method check. The paranoid may want  
> to pipe their log through a filter which replaces control chars with  
> some associated symbolic value.  
  
The paranoid may want to reconsider their logging entirely. Apache's  
"raw" logging of the request can result in more serious problems.  
Consider:  
  
$ telnet www.foo.com http  
Trying www.foo.com...  
Connected to www.foo.com.  
Escape character is '^]'.  
GET / HTTP/1.0" 404 -9999999 "  
  
This results in the following (combined format) log entry:  
  
aaa.bbb.ccc.ddd - - [07/Jan/1999:14:07:41 -0500] "GET / HTTP/1.0" 404 -9999999 "" 200 751 "-" "-"  
  
In the "combined" log format, the same technique is possible with the  
referer and user-agent, such that you can construct completely  
unparseable log entries. I made a small modification to the logging  
module to allow me to insert newlines to separate fields in the  
LogFormat string, as it seems to be that newlines are the only  
characters you can't weasel into a request.  
  
Sending a null, by the way, results in this interesting effect:  
  
209.54.21.199 - - [07/Jan/1999:14:35:27 -0500] "^?ô^?ý" 501 - "-" "-"  
  
(Perhaps that will be mutilated by non 8-bit mail transport.. it's the  
four characters ff f4 ff fd)  
  
To be fair, I should point out the following comment in the source code:  
  
"[...] Note that  
* there is no escaping performed on the strings from %r, %...i and  
* %...o; some with long memories may remember that I thought this was  
* a bad idea, once upon a time, and I'm still not comfortable with  
* it, but it is difficult to see how to "do the right thing" with all  
* of '%..i', unless we URL-escape everything and break with CLF."  
  
In case anybody cares, here is the patch I am using to "break with CLF":  
  
--- mod_log_config.c~ Tue Sep 22 05:19:59 1998  
+++ mod_log_config.c Wed Nov 18 01:39:25 1998  
@@ -126,6 +126,7 @@  
* sent to the client.  
* %...l: remote logname (from identd, if supplied)  
* %...{Foobar}n: The contents of note "Foobar" from another module.  
+ * %N: newline  
* %...{Foobar}o: The contents of Foobar: header line(s) in the reply.  
* %...p: the port the request was served to  
* %...P: the process ID of the child that serviced the request.  
@@ -364,6 +365,12 @@  
{  
return ap_table_get(r->notes, a);  
}  
+  
+static const char *log_newline(request_rec *r, char *a)  
+{  
+ return "\n";  
+}  
+  
static const char *log_env_var(request_rec *r, char *a)  
{  
return ap_table_get(r->subprocess_env, a);  
@@ -472,6 +479,9 @@  
},  
{  
'n', log_note, 0  
+ },  
+ {  
+ 'N', log_newline, 0  
},  
{  
'e', log_env_var, 0  
  
I then use this butt-ugly LogFormat directive:  
  
LogFormat "A %v%NB %h%NC %l%ND %u%NE %t%NF %r%NG %>s%NH %b%NI %{Referer}i%NJ %{User-Agent}i%N" combinedplus  
  
The log entries come out as follows:  
  
A www.netmonger.net  
B 209.54.21.140  
C -  
D -  
E [04/Jan/1999:17:16:59 -0500]  
F GET / HTTP/1.0  
G 200  
H 5094  
I -  
J mon.d/http.monitor  
  
I ran into this issue when I decided to nightly read the log files and  
send them to a database.. when writing a parser, one starts thinking  
about field delimiters, and I decided to check to make sure that I  
could actually rely on them.. I was rather started to find that I  
couldn't, but I didn't have time to write a proper bug report, so it's  
waited until this similar issue reminded me of the problem.  
--  
Christopher Masto Director of Operations NetMonger Communications  
[email protected] [email protected] http://www.netmonger.net  
  
"Good tools allow users to do stupid things." -- Clay Shirky  
  
----------------------------------------------------------------------------  
  
Date: Thu, 7 Jan 1999 16:00:05 -0500  
From: Jonathan A. Zdziarski <[email protected]>  
To: [email protected]  
Subject: Re: HTTP REQUEST_METHOD flaw  
  
Perhaps in the server source code there should be a feature to restrict  
the server to accepting only 'known request methods'. Either that or  
restricting the length would stop any buffer overflow attacks.  
  
Thank you,  
  
Jonathan A. Zdziarski  
Sr. Systems Administrator  
Netrail, inc.  
888.NET.RAIL x240  
  
----------------------------------------------------------------------------  
  
Date: Fri, 8 Jan 1999 17:00:30 -0500  
From: Kenneth Albanowski <[email protected]>  
To: [email protected]  
Subject: Re: HTTP REQUEST_METHOD flaw  
  
If I may pipe in, in my opinion this is strictly a failure of the logging  
mechanism, and the HTTP implementation (regardless of whether control  
characters are allowed or not allowed) is irrelevant. If data is being  
logged, that data should be logged unambigously, in a manner suitable for  
retrieval, and should be retrieved by an appropriate agent. If the logging  
mechanism cannot reliably or safely log some bytes, then something should  
be changed (I don't care what) so that those bytes are not logged. Very  
simple.  
  
The log format that fails to escape double quotes is a good example of an  
ambiguous logging format, and using cat or more (as opposed to less in  
non-raw mode) is a good example of using an improper log review mechanism.  
(The log is the place where concentrated evil is stored. Why would you  
feed that directly to your terminal? Do you know what back doors are in  
your terminal emulation code?)  
  
More constructively, how about changing the logging library used here so  
that is smart enough to reformat control characters safely and  
unambiguously (perhaps ^A => \01, ^B => \02, \ => \\, or something  
similar) and if the output of quoted strings is necessary, some method of  
telling it to escape the quotes used for a particular string.  
  
However, there is one trick available that can help decode strings with  
embedded quotes: if there is only _one_ such string in a block of data,  
and the end of the data is known with precision, just scan backwards from  
the end for the unambiguous last quote, and forwards from the beginning  
for the unambiguous first quote.  
  
--  
Kenneth Albanowski ([email protected], CIS: 70705,126)  
  
----------------------------------------------------------------------------  
  
Date: Wed, 13 Jan 1999 10:12:13 -0600  
From: monti <[email protected]>  
To: [email protected]  
Subject: test-cgi - Re: HTTP REQUEST METHOD flaw  
  
At least one exploitable application for throwing arbitrary characters  
into an HTTP request method is good old "test-cgi".  
  
The suggested (and from what I have seen on most systems, typical) fix  
for the origianl bug in this script was to put the "QUERY_STRING" variable  
in test-cgi in quotes to prevent its use for listing files.  
  
With mnemonix's post regarding the REQUEST METHOD's "feature", many users  
are re-exposed to the test-cgi problem, as the "REQUEST_METHOD" variable  
remains un-quoted in the following shell command:  
  
echo REQUEST_METHOD = $REQUEST_METHOD  
  
Instead of using "*" or a pathname followed by "*" as an argument to  
test-cgi as in:  
  
GET /cgi-bin/test-cgi?* HTTP/1.0  
  
An attacker could use something like the following"  
  
* /cgi-bin/test-cgi HTTP/1.0  
to see contents of /cgi-bin directory of web-root  
  
or  
  
/* /cgi-bin/test-cgi HTTP/1.0  
to see contents of the system's root /  
  
or whatever absolute or relative path from the webserver's cgi-bin.  
  
This was tested on version 1.3b6 of Apache.  
  
The fix is to surround all of the variables in test-cgi (and any other  
variations of test-cgi, such as nph-test-cgi, that may be present) in  
quotes.  
  
If there is a moral to this story, it is yet another warning about cgi  
programming and scripting; Protect *any* data that can be supplied by the  
user from overflow and/or unwanted interpretation in your application  
including variables that may not necessarily be directly user-supplied.  
  
The original test-cgi advisory can be found in the bugtraq archives at  
http://www.geek-girl.com/bugtraq  
  
-Eric Monti  
  
`