Hi Micha, On Thu, Oct 3, 2013 at 2:07 PM, Micha Lenk <[email protected]> wrote:
> Independent from how the HRS issue (CVE-2005-2088) was fixed at that > time, I still believe that it is a bad idea in terms of security to > flush the buffer and forward its content to the backend before the > *whole* request body has been received. mod_proxy won't forward anything before the whole request *header* is received (it isn't even called before), with or without my patch(es), and that prevent HRS provided the httpd checks Content-Length/Transfer-Encoding against http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#page-31(which is the case, at least in trunk). mod_proxy will also prevent HRS by checking that the received data do not exceed the announced size, again my patch(es) don't change that. It currently prefetches 16K of the body (if any) and forwards that and everything after to the backend from there, it won't retain the "*whole*" body unless one plays with the "proxy-sendcl" env. Do you mean you always setenv "proxy-sendcl" to force mod_proxy in full-fetching mode because of security issues ? > At least I would recommend to > carefully review this change to make sure you don't create a new > security issue similar to the HRS issue. > Sure, review and more testing is very welcome. I'm not sure what changes you are talking about, though. Is it about the "flushall" or the "prefetch before connect" patch ? For the first patch I don't see (as explained above) the changes about security, it is more about small network packet now vs big ones later. The latter case (the current default behaviour) also raises a backend timeout issue, when the client sends small but regular data fetched-but-not-flushed by the proxy (whether or not the bytes are the first ones) and the backend timeouts because it hasn't received anything since a while... For the second patch, do you mean pre-fetching (part of) the request body before connecting/reusing a backend could introduce a flaw ? You may be right but, IMHO, not for a HRS vulnerability (httpd/mod_proxy checks haven't been changed). Contrariwise, it avoids a DOS attempt on both the proxy and the backend (whose connections are requisitioned) should a client be slow (or Alice). > > Regards, > Micha >
