Re: [Mod-fcgid-users] security problem, possible DoS : fcgid large file uploading and input buffering

2007-05-09 Thread Janis Volbergs

On May 9, 2007, at 10:54 AM, Gabriel Barazer wrote:

 On 05/08/2007 21:41:41 +0200, Janis Volbergs [EMAIL PROTECTED] wrote:

 Why not limit maximum size of the data to be uploaded? This should be
 an easy patch to mod_fcgi. And about buffering, it would be more safe
 to have temporary files. However, this might get insecure, if the
 server has multiuser environment. E.g. other users might easily steal
 those files. So, it seems that there simply is no ultimate solution.


 I don't think limiting the input data size is a good workaround,  
 because
 FastCGI has to manage only the transport and communication between the
 FastCGI application server and the web server. Thus
 filtering/limiting/buffering has to be done by the FastCGI server, not
 the process manager (mod_fcgid in our case). I don't think the  
 transport
 layer has anything to do other than queuing up connections, then
 transmitting data over sockets. Hence my proposal of completely
 disabling the FastCGI buffering system, or replacing it by a REAL
 buffering system which buffers chunks of data (8192 bytes is a good
 average buffer size). CGI works like this.


I understand your point, but what I proposed would be a quick and  
simple patch that would resolve the security issue.

Though, your proposal would be more logic and would give more value  
added in future.

 And this is the right way to handle data : let the application server
 create temp file is his secured environment/jail/user rights, just as
 PHP or some other scripting langages do.



perhaps create a patch and propose for it's inclusion in the next  
release ;)

cheers,
j.



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users


Re: [Mod-fcgid-users] security problem, possible DoS : fcgid large file uploading and input buffering

2007-05-08 Thread Gabriel Barazer
Hello,

BTW, no one other than me is worried by the security problem due to 
large file uploading I described below ?

On 04/30/2007 15:21:29 +0200, Gabriel Barazer [EMAIL PROTECTED] wrote:

 Hello,
 
 I experienced recently some problmes since a customer is doing large 
 file uploads with PHP (which is run by mod_fcgid, of course) : It seems 
 mod_fcgid is consuming much memory when uploading a file to PHP. I found 
 in the source file fcgid_bridge.c:473 the problem : as said in the 
 source, the entire request (stdin/post input) is loaded into memory 
 before sending it to the fastcgi Application Server (PHP in our case). 
 Although it's a well workaround for dealing with slow clients, I think 
 this is not the good behavior to implement, here are the points 
 highlighted :
 - Uploading files is becoming a major security problem, since a DoS can 
 be triggered by uploading a very large file (I experienced some attacks 
 with 1/2GB over a fast connection)
 - Additionnally, Video (=large) file uploading is becoming more and more 
 popular, increasing the memory consumption.
 - Dealing with slow clients must be done by the appliction server, which 
 can take any appropriate measure (e.g. having a special queue processing 
 for slow clients)
 - Upload progress meter is not possible if all the input data is 
 buffered before sent to the fastcgi process. (see RFC1867 : File Upload 
 Progress hook handler)
 - Upload of large files is better handled by the fast cgi AS, because of 
 various method used to store the upload data during progress (at the 
 application level , not the communication level that fastcgi is). e.g. 
 PHP handles file upload by creating temporary files, which location of 
 these can be customised by a php.ini directive. I think this task has 
 not to be handled by the fastcgi layer (which serves as a comm./bridge 
 protocol, not a input processor)
 - There is no need for the fastcgi process manager to handle and buffer 
 slow clients : A FastCGI application designed to handle load can handle 
 multiple connections AND the mod_fcgid process manager already does 
 multiple connection management with the adaptive spawning feature for 
 application which are not multi-tasked/threaded. (I even know fastcgi 
 applications which embed a process manager themselves)
 
 
 What are the problems with slow clients :
 - Sending input is very long, not constant : e.g. with shaped 
 connections : data flow is sent by peaks foloowed by no data input for 
 a variable time.
 - Connection is longer busy at the Apache level, but at the fastcgi 
 application level too (the workaround of buffering all the input prevent 
 the fastcgi app from being busy buring the input loading).
 
 How to deal with this, my proposal :
 - What about buffering input like the output buffer, by chunks of, say, 
 8Kbytes ? The major problem is the time to fill the buffer : if the time 
 required to fill the buffer is too long, application can timeout, but I 
 think this is the normal behavior of an application to manage 
 communication timeout. What about don't buffering the input at all ? 
 This way the data flow AND the data flow rate can by processed by the 
 application (such as measuring the data flow rate to put a slow request 
 in a special queue).
 - Because maybe some users prefer the current behavior of buffering all 
 the input data, a compatibility switch would be a nice thing (e.g. 
 InputBuffering Off / On)
 
 What do you think about it ?
 
 BTW: who are the current maintainer(s) of this project ? The 
 documentation of this project is not very up-to-date and I had to read 
 the source code to know all the directives... Maybe can I be of some help ?
 
 Regards,
 
 Gabriel
 
 
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Mod-fcgid-users mailing list
 Mod-fcgid-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users


Re: [Mod-fcgid-users] security problem, possible DoS : fcgid large file uploading and input buffering

2007-05-08 Thread Janis Volbergs
Hi!

Why not limit maximum size of the data to be uploaded? This should be  
an easy patch to mod_fcgi. And about buffering, it would be more safe  
to have temporary files. However, this might get insecure, if the  
server has multiuser environment. E.g. other users might easily steal  
those files. So, it seems that there simply is no ultimate solution.

So, to sum up, directive for limiting maximum upload would be great.

j.

p.s. we don't have multiuser environment, so, temporary files would  
ease up life, as we are having c program as fcgid client - and that  
program now creates temp files itself.

On May 8, 2007, at 5:02 PM, Gabriel Barazer wrote:

 Hello,

 BTW, no one other than me is worried by the security problem due to
 large file uploading I described below ?

 On 04/30/2007 15:21:29 +0200, Gabriel Barazer [EMAIL PROTECTED]  
 wrote:

 Hello,

 I experienced recently some problmes since a customer is doing large
 file uploads with PHP (which is run by mod_fcgid, of course) : It  
 seems
 mod_fcgid is consuming much memory when uploading a file to PHP. I  
 found
 in the source file fcgid_bridge.c:473 the problem : as said in the
 source, the entire request (stdin/post input) is loaded into memory
 before sending it to the fastcgi Application Server (PHP in our  
 case).
 Although it's a well workaround for dealing with slow clients, I  
 think
 this is not the good behavior to implement, here are the points
 highlighted :
 - Uploading files is becoming a major security problem, since a  
 DoS can
 be triggered by uploading a very large file (I experienced some  
 attacks
 with 1/2GB over a fast connection)
 - Additionnally, Video (=large) file uploading is becoming more  
 and more
 popular, increasing the memory consumption.
 - Dealing with slow clients must be done by the appliction server,  
 which
 can take any appropriate measure (e.g. having a special queue  
 processing
 for slow clients)
 - Upload progress meter is not possible if all the input data is
 buffered before sent to the fastcgi process. (see RFC1867 : File  
 Upload
 Progress hook handler)
 - Upload of large files is better handled by the fast cgi AS,  
 because of
 various method used to store the upload data during progress (at the
 application level , not the communication level that fastcgi is).  
 e.g.
 PHP handles file upload by creating temporary files, which  
 location of
 these can be customised by a php.ini directive. I think this task has
 not to be handled by the fastcgi layer (which serves as a comm./ 
 bridge
 protocol, not a input processor)
 - There is no need for the fastcgi process manager to handle and  
 buffer
 slow clients : A FastCGI application designed to handle load can  
 handle
 multiple connections AND the mod_fcgid process manager already does
 multiple connection management with the adaptive spawning feature for
 application which are not multi-tasked/threaded. (I even know fastcgi
 applications which embed a process manager themselves)


 What are the problems with slow clients :
 - Sending input is very long, not constant : e.g. with shaped
 connections : data flow is sent by peaks foloowed by no data  
 input for
 a variable time.
 - Connection is longer busy at the Apache level, but at the fastcgi
 application level too (the workaround of buffering all the input  
 prevent
 the fastcgi app from being busy buring the input loading).

 How to deal with this, my proposal :
 - What about buffering input like the output buffer, by chunks of,  
 say,
 8Kbytes ? The major problem is the time to fill the buffer : if  
 the time
 required to fill the buffer is too long, application can timeout,  
 but I
 think this is the normal behavior of an application to manage
 communication timeout. What about don't buffering the input at all ?
 This way the data flow AND the data flow rate can by processed by the
 application (such as measuring the data flow rate to put a slow  
 request
 in a special queue).
 - Because maybe some users prefer the current behavior of  
 buffering all
 the input data, a compatibility switch would be a nice thing (e.g.
 InputBuffering Off / On)

 What do you think about it ?

 BTW: who are the current maintainer(s) of this project ? The
 documentation of this project is not very up-to-date and I had to  
 read
 the source code to know all the directives... Maybe can I be of  
 some help ?

 Regards,

 Gabriel



 - 
 
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Mod-fcgid-users mailing list
 Mod-fcgid-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users

 -- 
 ---
 This SF.net email