httpd and cgi

[Will <wi...@lxcenter.org>]

I was wondering how httpd handles POST requests to cgi.  Does it stream the 
body directly from the client to the cgi program?  If this is the case, what 
would be the downsides to streaming that to a file first and going from the 
file (most likely filesystem cache) to the stdin of the cgi program?  I 
think the obvious pro would be the cgi program would be open for a much 
shorter time.

-Will 

Re: httpd and cgi

[Will <wi...@lxcenter.org>]

I don't know how it can decide to allow the upload at all.  That is actually 
more easily built into the webserver itself, I think.

-Will

----- Original Message ----- 
From: "Graham Leggett" <mi...@sharp.fm>
To: <de...@httpd.apache.org>
Sent: Saturday, November 24, 2012 8:28 PM
Subject: Re: httpd and cgi


On 25 Nov 2012, at 3:17 AM, "Will" <wi...@lxcenter.org> wrote:

> The idea would be that the webserver would handle that file and send it to 
> cgi and delete it.

The web server would only handle the file when the upload of the file was 
complete. All the attacker needs to do is make sure lots of uploads start, 
upload 99% of their content, and then stop, never completing, and then 
repeat this pattern until you're out of disk.

In theory your CGI program would have had the power to decide before 
allowing the upload to start whether it was willing to accept the file, 
perhaps because the user was a trusted user, or because enough space was 
available on disk, but by placing your proposed stream-to-file in the way 
the CGI is no longer able to do that.

Regards,
Graham
--

Re: httpd and cgi

[Graham Leggett <mi...@sharp.fm>]

On 25 Nov 2012, at 3:17 AM, "Will" <wi...@lxcenter.org> wrote:

> The idea would be that the webserver would handle that file and send it to cgi and delete it.

The web server would only handle the file when the upload of the file was complete. All the attacker needs to do is make sure lots of uploads start, upload 99% of their content, and then stop, never completing, and then repeat this pattern until you're out of disk.

In theory your CGI program would have had the power to decide before allowing the upload to start whether it was willing to accept the file, perhaps because the user was a trusted user, or because enough space was available on disk, but by placing your proposed stream-to-file in the way the CGI is no longer able to do that.

Regards,
Graham
--

Re: httpd and cgi

[Will <wi...@lxcenter.org>]

The idea would be that the webserver would handle that file and send it to 
cgi and delete it.  But it is something to consider.  Thanks!

-Will

----- Original Message ----- 
From: "Graham Leggett" <mi...@sharp.fm>
To: <de...@httpd.apache.org>
Sent: Saturday, November 24, 2012 8:00 PM
Subject: Re: httpd and cgi


On 25 Nov 2012, at 1:59 AM, "Will" <wi...@lxcenter.org> wrote:

> I was wondering how httpd handles POST requests to cgi.  Does it stream 
> the body directly from the client to the cgi program?  If this is the 
> case, what would be the downsides to streaming that to a file first and 
> going from the file (most likely filesystem cache) to the stdin of the cgi 
> program?

This would allow anybody to DoS your server by filling up the disk on 
purpose and prevent further legitimate requests.

Regards,
Graham
--

Re: httpd and cgi

[Graham Leggett <mi...@sharp.fm>]

On 25 Nov 2012, at 1:59 AM, "Will" <wi...@lxcenter.org> wrote:

> I was wondering how httpd handles POST requests to cgi.  Does it stream the body directly from the client to the cgi program?  If this is the case, what would be the downsides to streaming that to a file first and going from the file (most likely filesystem cache) to the stdin of the cgi program?

This would allow anybody to DoS your server by filling up the disk on purpose and prevent further legitimate requests.

Regards,
Graham
--

Re: httpd and cgi

[Nick Kew <ni...@webthing.com>]

On 24 Nov 2012, at 23:59, Will wrote:

> I was wondering how httpd handles POST requests to cgi.  Does it stream the body directly from the client to the cgi program?  If this is the case, what would be the downsides to streaming that to a file first and going from the file (most likely filesystem cache) to the stdin of the cgi program?  I think the obvious pro would be the cgi program would be open for a much shorter time.

You could achieve that with an input filter that collects all POST data for
a request into a file, and returns it to the caller as a file bucket.  The
drawback is that it breaks pipelining the POST data, but perhaps that's
not an issue for you.

-- 
Nick Kew