You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2001/10/26 20:51:59 UTC
Re: DoS on POSTS
On Thursday 25 October 2001 08:52 pm, Ryan Bloom wrote:
> > It seems that there is a possibility for DoS on Apache servers
> > when doing a POST. On search.apache.org, I can send the following
> > request:
> >
> > PUT / HTTP/1.1
> > Host: search.apache.org:80
> > Content-Length: 1000
> > <newline here>
> >
> > And just let it sit there forever. search.apache.org is running 2.0.24,
> > and I'm running out of CVS and seeing the same behaviour. Seems bogus to
> > me.
>
> Well, after a few weeks of meaning to look into this, I finally have. Jon,
> you are 100% correct that this does happen. The problem is the
> handle_map_file handler. I have begun to track it down, but what is
> happening, is that the first request fails after the timeout is hit. The
> error page is requested, and that gets sent back to the
> ap_internal_redirect, but the content-length is still set, so the second
> request is hosed. Then we end up in an endless loop.
>
> I haven't really looked at how to fix this yet, and I have to write a part
> of my book tonight, but the first step is identifying the problem. This
> goes away if you remove all of the .var files from the config file BTW. I
> would suggest that if we don't fix ASAP, those lines should be removed from
> the apache.org site, and this MUST be fixed before we release the next
> beta.
Had more time to look at this. It looks like we actually will timeout given enough
time, but by default that time limit is like 10 minutes. I think this can be fixed
by setting the content-length to 0 when we go to serve error pages. I am
attempting this now-ish.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: DoS on POSTS
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 27 Oct 2001, William A. Rowe, Jr. wrote:
> Requesting this;
>
> POST /cgi-bin/printenv.pl HTTP/1.1
> Content-Length:80
> Host:localhost
>
> and stalling, I get a 5 minute pause, followed by;
>
> HTTP/1.1 200 OK
> Date: Sat, 27 Oct 2001 16:55:02 GMT
> Server: Apache/2.0.27-dev (Win32) DAV/2 mod_ssl/3.0a0 OpenSSL/0.9.6b
> Content-Length: 1553
> Connection: close
> Content-Type: text/plain; charset=ISO-8859-1
>
> [content snipped]
>
> Now that's not pretty. Why are we returning 200 when the input is insufficient
> for properly handling the request??? We strip the content-length, so the cgi
> wouldn't know what to expect; it can't handle the error itself!!!
>
> Correction, we don't strip the content length ???
>
> Jon, try from CVS head, I suspect the timeout may have been fixed since you
> first observed this behavior. As for other unacceptable behaviors, well...
You are on Win32. Unix may be broken. Haven't checked.
>
> Thoughts anyone? I'd expect such a request to 400 out.
408. Which will be logged, and may or may not be sent to the client.
Also note that I seem to recall some suggestions to hardcode the
post-to-a-page-that-doesn't-take-posts case to act as if there were
no request body to read. Don't do that. Not only is it unnecessary
and just a symptom of a deeper problem, but we need to read the
request body always or error out in a way that closes the connection
(and the second is last resort only).
Re: DoS on POSTS
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jon Travis" <jt...@covalent.net>
Sent: Saturday, October 27, 2001 1:24 AM
> Like I said in my follow up post to my original, you don't even
> need to post the data to actually have this occur. I telneted
> to the server, and let it sit there for like 47 minutes before
> I killed it. I never had it time out.
Requesting this;
POST /cgi-bin/printenv.pl HTTP/1.1
Content-Length:80
Host:localhost
and stalling, I get a 5 minute pause, followed by;
HTTP/1.1 200 OK
Date: Sat, 27 Oct 2001 16:55:02 GMT
Server: Apache/2.0.27-dev (Win32) DAV/2 mod_ssl/3.0a0 OpenSSL/0.9.6b
Content-Length: 1553
Connection: close
Content-Type: text/plain; charset=ISO-8859-1
[content snipped]
Now that's not pretty. Why are we returning 200 when the input is insufficient
for properly handling the request??? We strip the content-length, so the cgi
wouldn't know what to expect; it can't handle the error itself!!!
Correction, we don't strip the content length ???
Jon, try from CVS head, I suspect the timeout may have been fixed since you
first observed this behavior. As for other unacceptable behaviors, well...
Thoughts anyone? I'd expect such a request to 400 out.
Bill
Re: DoS on POSTS
Posted by Jon Travis <jt...@covalent.net>.
Like I said in my follow up post to my original, you don't even
need to post the data to actually have this occur. I telneted
to the server, and let it sit there for like 47 minutes before
I killed it. I never had it time out.
-- Jon
On Fri, Oct 26, 2001 at 11:51:59AM -0700, Ryan Bloom wrote:
> On Thursday 25 October 2001 08:52 pm, Ryan Bloom wrote:
> > > It seems that there is a possibility for DoS on Apache servers
> > > when doing a POST. On search.apache.org, I can send the following
> > > request:
> > >
> > > PUT / HTTP/1.1
> > > Host: search.apache.org:80
> > > Content-Length: 1000
> > > <newline here>
> > >
> > > And just let it sit there forever. search.apache.org is running 2.0.24,
> > > and I'm running out of CVS and seeing the same behaviour. Seems bogus to
> > > me.
> >
> > Well, after a few weeks of meaning to look into this, I finally have. Jon,
> > you are 100% correct that this does happen. The problem is the
> > handle_map_file handler. I have begun to track it down, but what is
> > happening, is that the first request fails after the timeout is hit. The
> > error page is requested, and that gets sent back to the
> > ap_internal_redirect, but the content-length is still set, so the second
> > request is hosed. Then we end up in an endless loop.
> >
> > I haven't really looked at how to fix this yet, and I have to write a part
> > of my book tonight, but the first step is identifying the problem. This
> > goes away if you remove all of the .var files from the config file BTW. I
> > would suggest that if we don't fix ASAP, those lines should be removed from
> > the apache.org site, and this MUST be fixed before we release the next
> > beta.
>
> Had more time to look at this. It looks like we actually will timeout given enough
> time, but by default that time limit is like 10 minutes. I think this can be fixed
> by setting the content-length to 0 when we go to serve error pages. I am
> attempting this now-ish.
>
> Ryan
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
Re: DoS on POSTS
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Friday, October 26, 2001 1:51 PM
> On Thursday 25 October 2001 08:52 pm, Ryan Bloom wrote:
> > > It seems that there is a possibility for DoS on Apache servers
> > > when doing a POST. On search.apache.org, I can send the following
> > > request:
> > >
> > > PUT / HTTP/1.1
> > > Host: search.apache.org:80
> > > Content-Length: 1000
> > > <newline here>
> > >
> > > And just let it sit there forever. search.apache.org is running 2.0.24,
> > > and I'm running out of CVS and seeing the same behaviour. Seems bogus to
> > > me.
> >
> > Well, after a few weeks of meaning to look into this, I finally have. Jon,
> > you are 100% correct that this does happen. [...]
>
> Had more time to look at this. It looks like we actually will timeout given enough
> time, but by default that time limit is like 10 minutes. I think this can be fixed
> by setting the content-length to 0 when we go to serve error pages. I am
> attempting this now-ish.
++1... we should never get to the error phase with any request post data remaining.
Bill