On Mon, Oct 17, 2011 at 5:16 AM, Kazu Yamamoto
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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel