Feature #1303
closedfcgi vulnerable to DoS
Description
affects all fgci applications including php.
10 parelell uploads will result in the 11,12,13,14 etc.. client beeing ignored
imo lighty should scale automaticly. ie start another instance if all 10 are blocked.
imagine an application with 5k users loged in avarage. that means about 10 requests a second. let each of those requests take 2 seconds then you'r doomed
to reproduce: compile and run the hello world example (i added a <form> tag, if i found the upload file field here i would attach it)
cp /dev/urandom /tmp/rand until it reached a reasonable big size
open the browser 10 times on the application url
start 10 uploads in parallel
open another browser window and try accessing the url.
be afraid.
-- Arvid Picciani <aep
Files
Updated by Anonymous over 16 years ago
aha after repoting the attach button apears. going to attach my file.
also sorry for the formating, i didn't know this thing ignores newlines
-- Arvid Picciani <aep
Updated by darix over 16 years ago
we dont support adaptive spawning atm. That said there is no way to dynamically launch new backends. But even if there would be a way to spawn new backends on request the DOS situation would be still there. you cant spawn an unlimited number of backends as they would exhaust all your resources on the server.
Updated by Anonymous over 16 years ago
apart from that somone told me the POST is saved to temp files to the fgci application should not be blocked while the data is sent.
i can see the temp file beeing opened by lighty, but the fgci application is blocked anyway durring the upload.
when you cancel the upload the scgi REMAINS locked, the fd remains open, and the tempfile remains on harddisk.
i'm not sure if either you don't understand the seriousness of this problem or it's me choosing the wrong software for the wrong situation.
-- Arvid Picciani <aep
Updated by ts77 over 16 years ago
not calling it a DoS but it would really help in scalability if lighty would first buffer the POST request (being it a file-upload or regular post) before reserving and sending to a backend.
Updated by Anonymous almost 16 years ago
Replying to ts77:
not calling it a DoS but it would really help in scalability if lighty would first buffer the POST request (being it a file-upload or regular post) before reserving and sending to a backend.
I have also run into this problem and had to switch back to apache because of it.
Updated by gstrauss almost 8 years ago
- Description updated (diff)
- Assignee deleted (
jan) - Missing in 1.5.x set to Yes
default behavior in lighttpd 1.4.40 buffers POST request to disk before contact backend.
Also available in: Atom