Bugtraq mailing list archives
Re: HTTP REQUEST_METHOD flaw
From: marcs () ZNEP COM (Marc Slemko)
Date: Wed, 6 Jan 1999 10:01:27 -0800
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.
Current thread:
- Buffer overflow in www.boutell.com cgic library, (continued)
- Buffer overflow in www.boutell.com cgic library Jon Ribbens (Jan 10)
- Sekure SDI Advisory: mSQL Remote Bug (fwd) Sekure SDI SSC (Jan 10)
- nmap udp scan kills Neware (ex-HDS) X-terminals. Andrew V. Kovalev (Jan 11)
- Re: nmap udp scan kills Neware (ex-HDS) X-terminals. Adam Shostack (Jan 12)
- Cisco Security Notice: Cisco IOS Syslog Crash security-alert () cisco com (Jan 11)
- Re: Tripwire mess.. Casper Dik (Jan 05)
- Re: Tripwire mess.. Chris Adams (Jan 05)
- Re: Tripwire mess.. Jon Torrez (Jan 05)
- Administrivia Aleph One (Jan 05)
- HTTP REQUEST_METHOD flaw mnemonix (Jan 06)
- Re: HTTP REQUEST_METHOD flaw Marc Slemko (Jan 06)
- Re: HTTP REQUEST_METHOD flaw Kragen Sitaker (Jan 07)
- Re: HTTP REQUEST_METHOD flaw pedward () WEBCOM COM (Jan 06)
- Re: Tripwire mess.. CyberPsychotic (Jan 07)
- Re: Tripwire mess.. Jon Speer (Jan 08)