Date: Wed, 6 Jan 1999 13:16:07 -0000 From: mnemonix To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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*" 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 To: BUGTRAQ@netspace.org 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 chris@netmonger.net info@netmonger.net 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 (kjahds@kjahds.com, CIS: 70705,126) ---------------------------------------------------------------------------- Date: Wed, 13 Jan 1999 10:12:13 -0600 From: monti To: BUGTRAQ@netspace.org 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