Re: [tcpm] Is this a problem?

[Mark Allman <[e-mail]>]

[catching up]

> We have documented a case of HTTP servers that are prone to resource
> starvation with the use of a small user level program. The program
> does not require any special privileges or changes in the kernel. The
> user level program on the client opens a connection to a HTTP server,
> sends a GET request for a large file (larger than the advertised
> window of the client) but never reads the response.
> 
> Three well-known, public sites were tested for this vulnerability. The
> two most common HTTP servers, Apache and IIS were the target. While
> one site had put mitigation technique in place, the others had
> none. With the latter two we were able to hold connections in
> ESTABLISHED state for days. The former site had a mitigation in place
> with a fixed timeout of 11 min., which was easy to guess and work
> around. 

I want to try to understand these experiments.  You used your program
against public, well-known sites, right?  I also assume you did this in
a sort of "one at a time" fashion, right?  That is, you didn't beat
these web sites with a zillion of your test connections.  Am I right
here?

If I read all this right then I don't understand how you can claim that
two of the three sites used **no mitigation** for the problem you
describe.  It seems to me that they could well have a mitigation that
kicks in when their resources are in high-demand (this is a resource
contention problem after all) and your one "malicious" connection did
not send them to that state.  This, of course, may not be the case.
But, I don't see how you can make the above claim.

allman

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm