[web-devel] questions about ResponseEnumerator

[Michael Snoyman]

On Mon, Oct 17, 2011 at 5:16 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
> Hello,
>
>> I think we need to be clear about what "vulnerability" means here.
>
> If you don't like the word vulnerability, sorry for that.

I wasn't playing with semantics; I have no problem calling it a
vulnerability. I just want to make sure we're talking about the same
thing.

> But the following DOS is possible. A bad guy can open massive HTTP
> connections to Warp and send partial bodies and keep the connections.
> The connections will not time out. If the limit of open-file reaches,
> Warp cannot accept a new connections from a good guy.

I had not understood that this was the DOS attack you were trying to
prevent, thank you for the clarification. I think you are correct that
this is a problem, but perhaps we should solve it in the enumSocket
function. If we tickle the timeout before calling Sock.recv and then
pause it again afterwards, we will *only* be timing out on the part of
the code that is receiving data from the client, as opposed to timing
out on the application code itself.

> If my understanding is correct, this happens not only for CGI but also
> for other services.
>
>> From Warp's perspective, there is no need to defend against the
>> application: if an application wants to spend five hours responding to
>> a request, that's the application's prerogative. I understand that in
>> the CGI case, you want to prevent something like that from happening,
>> but that's beyond Warp's purview. The question is can we expose enough
>> primitives to make it possible for you to implement this at the
>> Mighttpd level.
>
> Yes, applications are our friends. What I pointed out is that a bud
> guy can spend five hours. And during that, applicatons cannot spend
> even one second to do their service.
>
>> So from that perspective, I'm not sure if 96311d would really be
>> considered a vulnerability in Warp. Isn't your patch making it
>> impossible for an application to run in unbounded time? It might make
>> more sense to add a specific timeout each time the CGI app is called
>> (possibly via timeout[1]) to ensure it responds appropriately. But if
>> I'm not mistaken, this isn't even necessary in the CGI case, as the
>> Response value will be returned by your code and will not be affected
>> by the response time of the CGI app itself.
>
> The patch is just in a "proof of concept" level. We probably should
> prepare an option to let applications control time out by themselves.
>
> Warp should be secure by default. And an application should be able to
> open the door to the self-responsibility world if it wishes.
>
> --Kazu
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>