be cautious of dynamic allocation

[Marc Slemko <ma...@worldgate.com>]

A lot of the core of the server was _not_ written with dynamic allocation
in mind, and there were in mid 1.2 betas a _lot_ of places where avoiding
buffer overflows relied on the implicit assumption that there was a limit
on the size of certain things that was propogated down.

I'm not advocating that way of coding, and I think I have all of those
cases fixed, but it is just a caution that changing things to use dynamic
allocation can cause unforseen security side-effects due to other broken
code.

Re: be cautious of dynamic allocation

[Dean Gaudet <dg...@arctic.org>]

You mean psprintf() ?  I figured you'd complain first about the fact that
we might end up with something that chews lots of memory :) 

I'm pretty happy that you nailed cases during 1.2 beta... at least in the
core.  I'm pretty happy that you and I nailed a lot more cases in modules
in december for 1.2.5... but it'd still be cool if someone else did
another security review. 

Honestly what worries me more about dynamic allocation is where we
construct a long pathname that gets truncated when used by the OS and that
leads to a security problem.  In theory we should see ENAMETOOLONG ... but
maybe we don't do the right thing.  But if that problem exists it probably
existed before psprintf() as well -- because code would just use
HUGE_STRING_LEN or something, which is certainly larger than PATH_MAX on
any system I know of.

But I really like the cleanness of psprintf() versus all the stack buffers
here and there with ap_snprintf() and pstrdup().  It should be faster as
well although I haven't benchmarked it, it involves one less memcpy, and
one less strlen of all the characters... where it might lose that
pvsprintf() duplicates some code from palloc(), and that could stretch the
footprint in the instruction cache. 

Dean

On Mon, 30 Mar 1998, Marc Slemko wrote:

> A lot of the core of the server was _not_ written with dynamic allocation
> in mind, and there were in mid 1.2 betas a _lot_ of places where avoiding
> buffer overflows relied on the implicit assumption that there was a limit
> on the size of certain things that was propogated down.
> 
> I'm not advocating that way of coding, and I think I have all of those
> cases fixed, but it is just a caution that changing things to use dynamic
> allocation can cause unforseen security side-effects due to other broken
> code.
> 
> 
>