httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <...@mossflower.oit.unc.edu>
Subject Re: YA Apache DoS attack
Date Sat, 08 Aug 1998 17:29:39 GMT
You might be able to get most of the benefits of pools in this case by
just providing a realloc that just grows the buffer if it's the last thing
allocated. 

Simon
On Fri, 7 Aug 1998, Dean Gaudet wrote:

> You lose all the speed benefits of pools if you try any of this... (not to
> mention the simplicity, and the possibility of introducing memory leaks).
> 
> Remember, you're talking about deformed requests.  You don't want to put
> things into the path of well-formed requests.  (I don't care that HTTP
> allows these things to happen, I personally think that's a mistake.)  So
> my suggestion is to make a linked list of 4K buffers, and chop them up
> into headers as you can, or use them to figure out how long a header is
> and allocate the storage for the header in one step.
> 
> In the normal case the request fits in the first 4K, and there are no
> continuation headers, so you can build the headers_in table just by
> walking through the buffer and putting \0 here and there.  You don't need
> to allocate any extra memory. 
> 
> In the abnormal cases, such as a header spanning a buffer boundary, or
> continuation headers, you have to allocate extra memory... but that's no
> problem... you just calculate the size of memory you need, allocate, and
> assemble the bits and pieces. 
> 
> One difficulty is what to do with the "extra" data which is not part of
> the headers but which follows the headers... you essentially want to be
> able to push that back into the BUFF.  You only need one level of this
> sort of pushing, so support it directly -- it's a little magic with inptr. 
> 
> Dean
> 
> On Fri, 7 Aug 1998, Alexei Kosut wrote:
> 
> > On Fri, 7 Aug 1998, Jim Jagielski wrote:
> > 
> > > Ben Laurie wrote:
> > > > 
> > > > 
> > > > And here's a band-aid for 1.3.1 - I'm sure we'll come up with something
better
> > > > soon. This (untested) patch should prevent the worst effects. A similar
patch
> > > > should work for 1.2.x.
> > > 
> > > Even better would be to check the previous header with the present
> > > one and only increment if the same, since that's the only time this
> > > is a problem I think (could be wrong though).
> > 
> > Nope:
> > 
> > Header1: foo
> > Header2: bar
> > Header1: foo
> > Header2: bar
> > Header1: foo
> > Header2: bar
> > etc...
> > 
> > It strikes me that the 'best' way to handle this is to add a pfree, or
> > optimally a prealloc (since that may avoid even the copying that pstrcat
> > does). Of course, I'm well aware that the pool stuff is very unsuited to
> > this.
> > 
> > We could also give each table entry its own pool. Though that's probably a
> > worse idea.
> > 
> > Or we could use straight malloc/realloc/free for the tables, and register
> > cleanups for them. It would be a bit slower than taking memory straight
> > from the pool, but it's potentially much quicker when merging table
> > entries, and it obviously avoids the memory consumption problem we're
> > seeing here.
> > 
> > -- Alexei Kosut <akosut@stanford.edu> <http://www.stanford.edu/~akosut/>
> >    Stanford University, Class of 2001 * Apache <http://www.apache.org> *
> > 
> > 
> > 
> 
> 

Now available - The Freddy Hayek Kayak            | "Pass me another elf
Paddle Your Own Canoe! Be Rowed To Surfdom!       | Sergeant- this one's
>From The Taco Institute for Dyslexic Libertarians | split"
  Moments ago I had everything. Now, there's a cow in my nose - La Salla


Mime
View raw message