[Snort-devel] memory leak or .. ?

Dennis Fleurbaaij dennis at ...856...
Wed Oct 3 06:25:07 EDT 2001


I'm no qualified-snort-coder (tm) at all but by looking at the source 
the problem seems to be the packet defrag handler.

In the file spp_defrag.c we find:

/* Function: Tree * fraginsert(frag i, Tree * t)             */
/* Insert frag i into the tree t, if it is not already there.       */
/* Return a pointer to the resulting tree.                         */

Tree *fraginsert(frag i, Tree * t)


if(!new_tree_node || fragmemuse > MEMHARDLIM)
        ErrorMessage("Ran out of space\n");

Hmz so that means there is a memory-limit, let's find it..

spp_defrag.c:#define MEMHARDLIM           32000000  /* memory hardlimit 
threshold */

Geez, >32mb so IMHO if the stream takes up more then 32Mb of fragmented 
packets the defragger can't handle it,
In my opinion you should just bup that value up and seen what happens.

2nd problem

Please tell dragos :)

[root at ...857... snort-1.8.1-RELEASE]# grep Dragos *
snort.conf:# IP defragmentation support from Dragos Ruiu. There
spp_defrag.c:** Copyright (C) 2000,2001 Dragos Ruiu <dr at ...40...>
spp_defrag.c:        ErrorMessage("Got NULL *froot in ReassembleIP(), 
please tell Dragos\n");

In the file spp_defrag.c we find:

Tree *ReassembleIP(Tree *froot)
    if(froot == NULL)
        ErrorMessage("Got NULL *froot in ReassembleIP(), please tell 
        return NULL;

Okay so something is calling this function with null values ? pretty 
wierd, lets check it out some more

There is only one call to the function "ReassembleIP" an that is in void 
PreprocDefrag(Packet *p) (main function)

        /* now check if we have to reassemble anything... */
        if( !MF(p) )
            froot = ReassembleIP(froot);

This is inside the if statement:
    {  /* heads up, live fragments inbound  */

So it means that there has to be some frags.

Now for the if that leads to the call. the MF is defined as:

#define MF(x)       (x->mf)

In decode.h the mf flag is explained:
  u_int8_t mf;            /* more fragments flag */

and the p is just the "packet" so let's put this all together:

if not more fragments_on_the_way_to_here of the current packet then 
reassemble so it basically means that
all fragments of the stream are there and you can put it all together now.

It implies some flaw somewhere _OR_ somebody that is putting up REALLY 
wierd netwerok traffic.

But hey time is up for this show untill next time, other time same 
mailinglist ;)

  - Dennis Fleurbaaij (dennis at ...856...)

Pascal Bouchareine wrote:

>Love your thingie. It's running almost very fine on a distributed
>sensors architecture and handles totally around 200Mb/s of traffic
>with great results.
>However, I have some noticeable problems with it :)
>First, i use some of snort's rules to handle "flux enforcement". This is,
>i have a *lot* of ip addresses/classes and the like, put in some variables,
>and i have rules such as:
>alert tcp !$MYSQL 3306 -> any any (msg: "new mysql 3 server"; \
>                   flags: A+; content: "|2e 00 00 00 0a 33 2e|"; offset: 0; \
>                   depth: 7; classtype: policy;)
>I had to "patch" snort to be able to handle very-long-lines (>1024 chars)
>and very-long-variables (>256 IIRC). I did as in [1]. I though maybe you
>would like to know.
>My second problem is a bit complicated for me. Snort eats around 2/4k of memory
>per second, which sounds normal since you are caching data, but at some point,
>it comes out with:
>Oct  2 11:01:02 snoop3 snort: Ran out of space 
>Oct  2 11:01:02 snoop3 snort: Ran out of space 
>Oct  2 11:01:02 snoop3 snort: Got NULL *froot in ReassembleIP(), please tell Dragos 
>Oops. I'm guessing this is my fault - but i want to be sure. The system handles
>around 80Mb/s on the following configuration:
>Bi intel pIII-800 (some va-linux hw), FreeBSD 4.2-RELEASE, 512Mb of RAM.
>Snort is 1.8.1-RELEASE, the preprocessors are configured as follow:
>preprocessor defrag
>preprocessor stream4: detect_scans, noinspect
>preprocessor stream4_reassemble: clientonly, ports 21 23 25 53 80 110 111 143
>preprocessor telnet_decode
>preprocessor http_decode: 80 -unicode
>preprocessor rpc_decode: 111
>preprocessor bo: -nobrute
>Which, IIRC, should be able to handle 65535 simultaneous TCP flows, not
>more - is the Ran out of space is linked to this fact ?
>With the stream2 preprocessor, i had the same kind of memory problem but
>it ended up dumping core - If you want me to, i can send you the 
>"ldd/bt/disas $pc" analysis of the core produced by a -g compiled binary.
>Sorry for that long email, if you need any more testings on this case,
>i'm totally available.
>(i'm attaching the test rules/config we're currently using with snort)
>[1 - patch for snort to handle long variables]
><diff -u>
>--- snort-1.8.1-RELEASE/rules.c Wed Aug 15 07:54:35 2001
>+++ snort-1.8.1-RELEASE-new/rules.c     Mon Sep 17 16:24:01 2001
>@@ -67,6 +67,7 @@
> int cmpcount;           /* compare counter */
> #endif
>+#define STD_BUF 32768
> /****************************************************************************
>  *
>@@ -2036,7 +2037,7 @@
>         enbracket = strrchr(tmp, (int)']'); /* null out the en-bracket */
>         if(enbracket) *enbracket = '\x0';
>-        toks = mSplit(tmp+1, ",", 128, &num_toks, 0);
>+        toks = mSplit(tmp+1, ",", 512, &num_toks, 0);
> #ifdef DEBUG
>         printf("mSplit got %d tokens...\n", num_toks);

Met vriendelijke groet,

Dennis Fleurbaaij

Voorzitter Stichting CORE
Tel : +31 (0) 6 54 21 53 65
Mail: dennis at ...856... 

More information about the Snort-devel mailing list