Re: [tcpm] Is this a problem?

Mark Allman <> Mon, 19 November 2007 13:38 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iu6pH-0000WF-HP; Mon, 19 Nov 2007 08:38:11 -0500
Received: from tcpm by with local (Exim 4.43) id 1Iu6pF-0000Ua-F1 for; Mon, 19 Nov 2007 08:38:09 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Iu6pF-0000UN-4a for; Mon, 19 Nov 2007 08:38:09 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1Iu6pC-0000oc-Hu for; Mon, 19 Nov 2007 08:38:09 -0500
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id lAJDc5Kj012096; Mon, 19 Nov 2007 05:38:05 -0800
Received: from ( []) by (Postfix) with ESMTP id 9E60212199C9; Mon, 19 Nov 2007 08:37:59 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id A2CBE2F5CE0; Mon, 19 Nov 2007 08:35:29 -0500 (EST)
To: Mahesh Jethanandani <>
From: Mark Allman <>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Who Made Who
MIME-Version: 1.0
Date: Mon, 19 Nov 2007 08:35:29 -0500
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1694300707=="

[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

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.


tcpm mailing list