Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44935BFA.9020000@hanik.com>
Date: Fri, 16 Jun 2006 20:33:46 -0500
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Tomcat Comet Model, DOS example
References: <44933E5B.1080903@hanik.com>
 <449340FD.9090207@apache.org>	 <44934503.2090803@hanik.com>
 <4493472C.4090304@apache.org>	 <44934936.9000906@hanik.com>
 <96e4b5230606161751j6c7c1f9el3d55659c45238bd9@mail.gmail.com>
In-Reply-To: <96e4b5230606161751j6c7c1f9el3d55659c45238bd9@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I agree, chunked would be the way to go for a communication.

I reverted my fix, however, now TC6 has a DOS possibility, by following 
these steps

1. Override CometServlet.read, always return true (you wanna serve N 
client requests, and you don't know how many its gonna send, so this is 
not unreasonable)
2. Client sends data with Content-Length
    POST /comet?count=001 HTTP/1.1\r\n
    Host: 127.0.0.1:8080
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) 
Gecko/20060124 Firefox/1.5.0.1\r\n
    Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
    Accept-Language: en-us,en;q=0.5\r\n
    Accept-Encoding: gzip,deflate\r\n
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
    Keep-Alive: 300\r\n
    Connection: keep-alive\r\n
    Content-Type: text/plain\r\n
    Content-Length: 16\r\n
    \r\n
    submit=value8888
3. client then sends any data (http request, garbage, anything)
4. Tomcat server hangs in a loop on that thread

5. Repeat steps 1-4 for as many as there are threads in the pool, and we 
have DOS
  
Filip


Costin Manolache wrote:
> Not sure I understand all details here - but chunking seems like a better
> solution
> than sending a bad Content-Length.
>
> Sending a too large or incorrect content-length may break a lot of 
> things (
> and be rejected,
> affect proxies, etc ).
>
> Costin
>
>
> On 6/16/06, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>>
>> Remy Maucherat wrote:
>> > Filip Hanik - Dev Lists wrote:
>> >> yes, but to do so, you would be required to pre calculate the content
>> >> length for the 2 (or N events), and if the server hasn't responded
>> >> (since its async) you can't send the 2nd event as you could start a
>> >> new HTTP request on the same connection when there hasn't been a
>> >> response. So to open your self up for async push for both client and
>> >> server, you omit content length, or set it to an extremely large 
>> value.
>> >>
>> >> see where I am getting it?
>> >
>> > Yes, I do.
>> >
>> > Comet "designers" got the idea too (most likely they want to work
>> > somewhat with proxies), and so Comet must use chunking on input (as
>> > any decent HTTP user agent would do automagically) and output (Tomcat
>> > will do it automagically too). This way it works without breaking the
>> > protocol and without having to compute the total length of the
>> > request/response beforehand. Of course, you can have easy testing of
>> > the code by using (fake) large content-length values like I did, but
>> > that's for local testing only.
>> how can tomcat know the Content-Length down to the client, when servlets
>> and JSP call flushBuffer, or the response(s) are two big to fit in the
>> buffer?
>> At that point, its up to the servlet programmer to send the content
>> length, but again, how would they know in advance the size of the total
>> response,
>>
>> so chunking becomes difficult
>> Filip
>>
>> >
>> > Rémy
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > For additional commands, e-mail: dev-help@tomcat.apache.org
>> >
>> >
>>
>>
>> -- 
>>
>>
>> Filip Hanik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.0/367 - Release Date: 6/16/2006
>   


-- 


Filip Hanik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org