On Tue, Jan 09, 2007 at 12:15:02AM -0600, William A. Rowe, Jr. wrote:
>
> bugtraq wrote:
> >
> > a quick fix for this can be available at least on bsd, there is accf_http
> > that can be modified not to pass the connection to apache until a full
> > request
> > is read (either get or post, full
bugtraq wrote:
>
> a quick fix for this can be available at least on bsd, there is accf_http
> that can be modified not to pass the connection to apache until a full request
> is read (either get or post, full, not just the first get request header,
> of course this can be even worst for a lot o
to kill is enough not to finish the request and let it timeout on server side.
no ddos/dos protection layers can stand against this attack (as far as i know)
and the scenario is simple
1. fingerprint the timeout on serverside
2. dig the sitemap from target
3. build a list of browsers to advertis
On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:
> Michal Zalewski wrote:
> > I feel silly for reporting this, but I couldn't help but notice that
> > Apache and IIS both have a bizarro implementation of HTTP/1.1 "Range"
> > header functionality (as defined by RFC 2616). Their implementations allow
On Thu, 4 Jan 2007, Michal Zalewski wrote:
> On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:
>
> 2) Theoretical window size limits and commonly implemented settings do
> have a side effect of making such attacks more feasible for
> attackers with a very limited bandwidth available. The
On Thu, Jan 04, 2007 at 12:45:35PM +0100, Pieter de Boer wrote:
> Michal Zalewski wrote:
> > 2) Negotiate a high TCP window size for each of the connections (1 GB
> > should be doable),
> >
> For instance, FreeBSD by default has TCP send buffers set to 32KB. It
> does not (apart from recent
Michal Zalewski wrote:
> 1) Connect to the server (as many times as allowed by the remote party
> or deemed appropriate for the purpose of this demonstration),
>
> 2) Negotiate a high TCP window size for each of the connections (1 GB
> should be doable),
>
> 3) Send a partial requ
Michal Zalewski wrote:
2) Negotiate a high TCP window size for each of the connections (1 GB
should be doable),
Just zooming in on one detail of your e-mail. While you could set your
own TCP receive window to 1GB, you obviously can't set the sender's send
window to 1GB if it doesn't w
On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:
> On the matter of your 1GB window (which is, again, the real issue), you have
> any examples of a kernel that permits that large a sliding window buffer by
> default
No, I simply mentioned the hypothetical maximum; common configurations for
high-pe
Michal Zalewski wrote:
> On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:
>
>> If you have an issue with this behavior, of HTTP, then you have an issue
>> with the behavior under FTP or a host of other protocols.
>
> Not really; see above. These are typically well known, preventable by
> configuri
On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:
> Seriously, HTTP pipelining can accomplish EXACTLY the same thing with minimal
> pain.
No, it can't. Client-side pipelining using simultaneous sessions with
keep-alives is usually severely restricted on server-side (exactly for the
reason they can
Michal Zalewski wrote:
> I feel silly for reporting this, but I couldn't help but notice that
> Apache and IIS both have a bizarro implementation of HTTP/1.1 "Range"
> header functionality (as defined by RFC 2616). Their implementations allow
> the same fragment of a file to be requested an arbitra
I feel silly for reporting this, but I couldn't help but notice that
Apache and IIS both have a bizarro implementation of HTTP/1.1 "Range"
header functionality (as defined by RFC 2616). Their implementations allow
the same fragment of a file to be requested an arbitrary number of times,
and each re
13 matches
Mail list logo
