[Snort-devel] I think I got it

Phil Wood cpw at ...86...
Mon Jul 30 23:36:57 EDT 2001


On Mon, Jul 30, 2001 at 08:48:32PM -0400, Jed Pickel wrote:
> Phil, 
> 
> You are quite the bug hunter! Thanks for taking the database plugin
> off the hook. :) It still strikes me as strange that (at least in your
> case) other bugs manifesting were dependent on whether or not the db

Not strange, all the plugins are using malloc/free to do their job.
stream4 free'd an array, but neglected to remove a memory of the pointer
which is needed further along in the detect cycle for the particular
stream, so that it can be flushed (AlertFlushStream).  Unfortunately,
p->ssnptr was pointing to memory that had been free'd because the input
plugin had realized that the packet was so bogus, it could not be part
of a real stream.  (at least that's my take.  it could be for some other
reason entirely.  I'm new to this application).

It just so happened that the database plugin was did a malloc and got
a buffer which coincided with some of the old stream4 space.  If it
wasn't your process, it could have been another output process that
did some malloc's.

> plugin was enabled. So I'll experiment with removing the malloc/free
> cycle for each alert and see if using automatic variables changes
> this.

I believe that you could get away with creating the necessary storage
either statically, or when called as local arrays.  I would pick which
ever method caused the least number of cycles.  I like static, cause
memory is cheap and you formalize the use and can't interfer with other
routines.  I think that would cut down on alot of malloc / free subroutine
calls.

However, any system which is as complex as snort, can, with a little
mind fart, modify any memory currently assigned to the process.
 
> 
> * Jed

-- 
Phil Wood, cpw at ...86...





More information about the Snort-devel mailing list