[Snort-devel] Defrag preprocessor crashing (was RE: [Snort-users] Stream4 and other stuff)

Dragos Ruiu dr at ...40...
Mon Jul 2 11:27:32 EDT 2001


I'm up now.... the hardmemlimit hit whoa... ok ...

In theory there shouldn't be a need todeallocate because
fragments should time out.  

If it's not the count going negative.... (which I thought I tried to account
for... just in case.... ) But I guess I can add some explicit deallocation
sweeping in this case.

I'll have a look and e-mail a fresh copy to you shortly.

cheers,
--dr 

On Mon, 02 Jul 2001, Martin Roesch wrote:
> "Mayers, Philip J" wrote:
> > 
> > It's certainly working a lot better now. However, the defrag preprocessor
> > seems to be having problems (I had thought we were running it before, but
> > maybe not). It runs fine for a short while, then snort goes wild:
> 
> Well, I'm glad to see that stream4 is at least working better now. :) 
> Once Dragos gets out of bed he'll come up with a good solution for this
> problem in spp_defrag.  I see the problem (when defrag runs out of
> memory it just tells you about it instead of forcing some
> deallocation).  Interesting that it's running out though, he's got a
> 32MB limit on the buffering, I can't imagine that you actually see that
> much fragmented traffic.  I wonder if the counter that Dragos is using
> is going negative (wrapping) someplace and that's causing the problem...
> 
> I added a quick fix so that Reassemble IP won't try to walk on NULL
> trees.  
> 
> Could you print out fragmemuse ('p fragmemuse' in gdb) and let me know
> what it looks like?
> 
> > diff -r1.17 spp_stream4.c
> > 477c477
> > <               s4data.track_stats_flag = 1;
> > ---
> > >               s4data.state_alerts = 0;
> 
> Fixed.
> 
> > Otherwise noalerts doesn't work. Also, the session log is *very* useful, but
> > it would be nice if there were a more compact/machine readable format
> 
> Ok, I'll make two formats, one for machines and one for humans. :)
> 
> 
> Look for a CVS commit in about 30 minutes.
> 
>      -Marty
> 
> > 
> > Regards,
> > Phil
> > 
> > +----------------------------------+
> > | Phil Mayers, Network Support     |
> > | Centre for Computing Services    |
> > | Imperial College                 |
> > +----------------------------------+
> > 
> > -----Original Message-----
> > From: Martin Roesch [mailto:roesch at ...402...]
> > Sent: 02 July 2001 04:34
> > To: Mayers, Philip J
> > Cc: snort-users; snort-dev
> > Subject: Re: [Snort-users] Stream4 and other stuff
> > 
> > Ok, try again.  I reimplemented the packet storage strategy over the
> > weekend and hopefully it's more stable now.  Download build 35 and let
> > me know how it goes.
> > 
> >     -Marty
> > 
> > "Mayers, Philip J" wrote:
> > >
> > > Command line arguments are:
> > >
> > > -A fast -b -c /usr/local/etc/snort.conf -e -g snort -u snort -i eth1 'not
> > > port (80 or 161) and not net (192.168.0.0/16 or 172.16.17.112/28) and not
> > > icmp'
> > >
> > > It seems to run for a few seconds, and then:
> > >
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > Rule application order: ->activation->dynamic->alert->pass->log
> > >
> > >         --== Initialization Complete ==--
> > >
> > > -*> Snort! <*-
> > > Version 1.8-beta8 (Build 30)
> > > By Martin Roesch (roesch at ...16..., www.snort.org)
> > > WARNING: Data on unestablished session (state: 7)!
> > > WARNING: Data on unestablished session (state: 7)!
> > > WARNING: Data on unestablished session (state: 9)!
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > DeleteSpd (spd=0x3, log=0) at spp_stream4.c:1584
> > > 1584        if(spd->next != NULL)
> > > (gdb) bt
> > > #0  DeleteSpd (spd=0x3, log=0) at spp_stream4.c:1584
> > > #1  0x80741df in DeleteSpd (spd=0x8322218, log=0) at spp_stream4.c:1586
> > > #2  0x80741df in DeleteSpd (spd=0x8321e30, log=0) at spp_stream4.c:1586
> > > #3  0x8074196 in DropSession (ssn=0x833dad0) at spp_stream4.c:1570
> > > #4  0x80734cd in ReassembleStream4 (p=0xbffff0b0) at spp_stream4.c:892
> > > #5  0x80558e2 in Preprocess (p=0xbffff0b0) at rules.c:3423
> > > #6  0x804b4ef in ProcessPacket (user=0x0, pkthdr=0xbffff560, pkt=0x80d780a
> > > "") at snort.c:510
> > > #7  0x8075272 in pcap_read ()
> > > #8  0x8075c2f in pcap_loop ()
> > > #9  0x804c87f in InterfaceThread (arg=0x0) at snort.c:1433
> > > #10 0x804b3bf in main (argc=14, argv=0xbffff744) at snort.c:443
> > > #11 0x40157f31 in __libc_start_main (main=0x804ad70 <main>, argc=14,
> > > ubp_av=0xbffff744, init=0x804a240 <_init>,
> > >     fini=0x807f6c0 <_fini>, rtld_fini=0x4000e274 <_dl_fini>,
> > > stack_end=0xbffff73c) at ../sysdeps/generic/libc-start.c:129
> > > (gdb) print spd
> > > $1 = (StreamPacketData *) 0x3
> > >
> > > Urk! Not good...
> > >
> > > (gdb) up
> > > #1  0x80741df in DeleteSpd (spd=0x8322218, log=0) at spp_stream4.c:1586
> > > 1586            DeleteSpd(spd->next, log);
> > > (gdb) l
> > > 1581        if(spd == NULL)
> > > 1582            return;
> > > 1583
> > > 1584        if(spd->next != NULL)
> > > 1585        {
> > > 1586            DeleteSpd(spd->next, log);
> > > 1587        }
> > > 1588
> > > 1589        /*if(log && (pv.log_bitmap & LOG_TCPDUMP))
> > > 1590        {
> > > (gdb) print spd
> > > $2 = (StreamPacketData *) 0x8322218
> > > (gdb) print *spd
> > > $3 = {next = 0x3, pkt = 0x41 <Address 0x41 out of bounds>,
> > >   payload = 0x4025e340
> > >
> > "8a%@8a%@(\0362\b\030\"2\bH\0372\bH\0372\bPa%@Pa%@Xa%@Xa%@`a%@`a%@ha%@ha%@pa
> > > %@pa%@xa%@xa%@\200a%@\200a%@\210a%@\210a%@\220a%@\220a%@( 2\b( 2\b a%@
> > >
> > a%@?a%@?a%@?a%@?a%@,a%@,a%@Aa%@Aa%@Ea%@Ea%@Da%@Da%@Oa%@Oa%@aa%@aa%@ea%@ea%@?
> > > a%@?a%@oa%@oa%@", pkth = {ts = {tv_sec = 137502248, tv_usec = 137616362},
> > > caplen = 993823709, pktlen = 121425}, seq_num = 96, payload_size = 96,
> > >   pkt_size = 0}
> > >
> > > I'll keep the gdb session open, in case you want more info...
> > >
> > > Regards,
> > > Phil
> > >
> > > +----------------------------------+
> > > | Phil Mayers, Network Support     |
> > > | Centre for Computing Services    |
> > > | Imperial College                 |
> > > +----------------------------------+
> > 
> > --
> > Martin Roesch
> > roesch at ...402...
> > http://www.sourcefire.com - http://www.snort.org
> > 
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/snort-devel
> 
> --
> Martin Roesch
> roesch at ...402...
> http://www.sourcefire.com - http://www.snort.org
> 
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel
-- 
Dragos Ruiu <dr at ...9...>   dursec.com ltd. / kyx.net - we're from the future 
gpg/pgp key on file at wwwkeys.pgp.net or at http://dursec.com/drkey.asc

_______________________________________________
Snort-users mailing list
Snort-users at lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users





More information about the Snort-devel mailing list