You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2006/06/17 03:33:46 UTC
Re: Tomcat Comet Model, DOS example
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 <de...@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
Re: Tomcat Comet Model, DOS example
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>>> Right now I'm not hot about reading the data first in the container:
>>> if done, it should be in InputBuffer,
>> yes, that is how I suggested it to be done. The AprBuffer was reading
>> the socket data in my checkin.
>>
>>> but could mean automagically discarding data, which could become a
>>> very sneaky problem if the user doesn't code the right way but is
>>> interested in the data.
>> yes, I prefer delivering the data. option 1
>
> The point of your patch was not to preread the data as you are now
> claiming, but instead about accepting entity bodies from invalid
> requests. As I said, I prefer the current mechanism.
I see your point, and fair enough, chunked is the way to go for multi
client requests, brings a question to my mind. my patch delivered the
data. but if you don't wanna do that, you should at least discard the
data and never invoke read, (and maybe even terminate the connection)
and this is the problem I'm trying to address, to deliver or not to
deliver the data I can live with, as you are correct on the content
length, that was just one part of it, its the loop I'm trying to avoid.
Lets name that problem 1.
Problem 2. If the client aborts its connection while the async servlet
is writing, we have yet another VM crash.
I believe problem 1 and 2 are all valid problems, and if you don't mind,
I'll delve deeper into these to see how we can avoid them. I'll provide
patches for review,
how does that sound,
Filip
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> Right now I'm not hot about reading the data first in the container:
>> if done, it should be in InputBuffer,
> yes, that is how I suggested it to be done. The AprBuffer was reading
> the socket data in my checkin.
>
>> but could mean automagically discarding data, which could become a
>> very sneaky problem if the user doesn't code the right way but is
>> interested in the data.
> yes, I prefer delivering the data. option 1
The point of your patch was not to preread the data as you are now
claiming, but instead about accepting entity bodies from invalid
requests. As I said, I prefer the current mechanism.
>> There are still some serious problems though, starting with the
>> current C2B and B2C converters which use far too much memory. I would
>> like to use the NIO converters instead, but they want to use
>> ByteBuffer and CharBuffer.
> yes, and ByteBuffer and CharBuffer have historically been slower than
> byte[] and char[], not sure if that is still the case.
I was talking about character encoding and decoding, which right now
sucks and is using tons of memory.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 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)
>
> I fail to see why doing that is reasonable: you're getting an event to
> read data, so you have to read it even if you're not going to use it
> (as in NIO).
yes, and since I am receiving the read event, I'm expecting data, no
data was available, so I return true to wait for it become available.
Tomcat fails to deliver the data, even though it issues a read(req,resp)
event.
Two solutions
1. Deliver the data (my reverted checkin)
2. Read the socket, discard the data, never call read
> Right now I'm not hot about reading the data first in the container:
> if done, it should be in InputBuffer,
yes, that is how I suggested it to be done. The AprBuffer was reading
the socket data in my checkin.
> but could mean automagically discarding data, which could become a
> very sneaky problem if the user doesn't code the right way but is
> interested in the data.
yes, I prefer delivering the data. option 1
>
> There are still some serious problems though, starting with the
> current C2B and B2C converters which use far too much memory. I would
> like to use the NIO converters instead, but they want to use
> ByteBuffer and CharBuffer.
yes, and ByteBuffer and CharBuffer have historically been slower than
byte[] and char[], not sure if that is still the case.
>
> Rémy
so where do we stand, you cool now? can I go back and work on my
checkin, improve it, and continue working on the Comet feature?
Filip
>
> ---------------------------------------------------------------------
> 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
Re: Tomcat Comet Model, DOS example
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 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)
I fail to see why doing that is reasonable: you're getting an event to
read data, so you have to read it even if you're not going to use it (as
in NIO). Right now I'm not hot about reading the data first in the
container: if done, it should be in InputBuffer, but could mean
automagically discarding data, which could become a very sneaky problem
if the user doesn't code the right way but is interested in the data.
There are still some serious problems though, starting with the current
C2B and B2C converters which use far too much memory. I would like to
use the NIO converters instead, but they want to use ByteBuffer and
CharBuffer.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org