[8977] in bugtraq

home help back first fref pref prev next nref lref last post

Re: HTTP REQUEST_METHOD flaw

daemon@ATHENA.MIT.EDU (Marc Slemko)
Thu Jan 7 15:59:02 1999

Date: 	Wed, 6 Jan 1999 10:01:27 -0800
Reply-To: Marc Slemko <marcs@ZNEP.COM>
From: Marc Slemko <marcs@ZNEP.COM>
X-To:         mnemonix <mnemonix@GLOBALNET.CO.UK>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <003b01be3976$b983cf60$216610ac@mercury>

On Wed, 6 Jan 1999, mnemonix wrote:

> 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.

It isn't a "feature", it is a feature.  Well, at least in Apache.  It is
there on purpose to allow support for new and/or nonstandard methods.

> 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

In many or most cases, there are numerous other ways to do the same thing.

eg. simply access "http://server/cgi-bin/printenv?^H^H^H^Hfoo".  If the
script uses the query string, you can often use pathinfo (eg.
http://server/cgi-bin/printenv/^H^H^H^Hfoo?this) for the same thing.  Or
you can do the same with with the protocol.

There are also various other things that can be done if you allow
arbitrary users write access to your terminal, which is essentially what
you are doing if you are using anything like cat or tail on your error
logs.

Depending on what sort of terminal you use and what sort of features it
supports via escape characters, you may or may not want to reconsider
using such methods without running them through some sort of filter.

[...]
> This was tested on Apache 1.3.3 on RedHat 5.2 and Apache 1.2.7 on RedHat

There is no Apache 1.2.7.

There is, however, a more important issue that this same feature of
allowing arbitrary methods to be passed to CGIs can result in.  Many
people, for some reason, insist on using the "Limit" directive whenever
they configure any access restrictions.

For example, they may do:

<Limit GET POST>
order deny,allow
deny from all
allow from 10.0.0
</Limit>

to deny all access to hosts outside of 10.0.0.0/24.  That is incorrect.
In normal situations, it doesn't always lead to much of a security risk.
With many CGIs, it does.  That is because many CGIs do not properly check
what method they are called with and refuse requests if they don't
understand the method.  That means it is impossible[0] to list every
method that could be used to call a script, since Apache allows for
arbitrary methods to be used.

The answer, of course, is quite simple: don't use a limit directive unless
you only want to limit particular methods.  If you want to limit all
methods, simply leave it out.  If you ever see any Limit directive used
anywhere, take a second look because the vast majority of them are used
incorrectly.

This certainly isn't a new issue, and certainly isn't anything that hasn't
been said over and over, and isn't a bug in Apache but a bug in a user's
configuration, but people still seem to have trouble getting the message.

home help back first fref pref prev next nref lref last post