httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r218978 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
Date Thu, 14 Jul 2005 11:43:35 GMT
On 7/13/05, wrowe@apache.org <wrowe@apache.org> wrote:

>   How can I fix thee?  let me count the ways...
> 
>   * pass a chunked body always (no-body requests don't go chunked).

We tried to send C-L whenever practical because it is common for a
origin server not to be able to handle chunked.  It looks like the
default configuration will be broken for some folks with input
filters, such as origin server = Apache mod_cgi, or origin server =
IIS (somebody else's comments).  So previously we optimized for
fool-proof operation instead of efficiency, and the administrator
could tune for efficiency if they could determine that there was no
issue with the back-end server handling chunked.

>   * validate that the C-L counted body length doesn't change.

It looks like we are counting bytes after they go through input
filters here, and then comparing that byte count with the specified
C-L header field.  That doesn't have to match since filters can change
the size.  (Admittedly I'm probably misunderstanding something.)

>   * follow RFC 2616 for C-L / T-E in the request body C-L / T-E
>     election logic.

Can you be more specific about what exactly had to be done for RFC
2616 conformance?

>   * do not forward HTTP/1.0 requests as HTTP/1.1, unless the admin
>     configures force-proxy-request-1.1

What is the harm?  The potential value is that the administrator can
tell us to use chunked iin the case where there is an input filter and
the origin server can handle chunked.

http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=218978&r1=218977&r2=218978&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/CHANGES (original)
> +++ httpd/httpd/trunk/CHANGES Wed Jul 13 20:42:22 2005
> @@ -1,12 +1,19 @@
>  Changes with Apache 2.1.7
>    [Remove entries to the current 2.0 section below, when backported]
> 
> +  *) SECURITY: CAN-2005-2088
> +     proxy: Correctly handle the Transfer-Encoding and Content-Length
> +     headers, discard the request Content-Length whenever T-E: chunked
> +     is used, always passing one of either C-L or T-E: chunked whenever
> +     the request includes a request body, and no longer upgrade HTTP/1.0
> +     requests to the origin server as HTTP/1.1.  Resolves an entire class
> +     of proxy HTTP Request Splitting/Spoofing attacks.  [William Rowe]

I'm so confused while trying to draw the line between

alternate RFC-compliant philosophy
fixes for actual RFC violations
fixes for security issues

I think CHANGES should be crystal clear on what change has a security
implication.

Mime
View raw message