Re: 1.8.4-beta1 feedback? core dumping

[Phil Wood <cpw () lanl gov>]

Marty,

I'm getting a core dump.  I've was getting them at the very end of a run
(not always).  I added some printfs in the CleanExit code to see how far
it was getting before dumping.  It would regularly core dump upon making
the call the stream4 cleanup code.  The idx list (of cleanerupers) had been
clobbered, so that the "next" cleanup (which should have been zero) was
some data from a packet.  So, I commented out the little loop which went
through the idx list (in CleanExit) so snort would not core dump.  All was
well for last week.  

I'm thinking there is some nimda like code that is deadly to snort.

However, today (Feb 11), I started getting core dumps in quick succession.
(I have a script which wakes up when snort dies and usually starts another
copy, however there is a "delta" I use to say "hey, this is rediculous" and
just stop looping)  Well, my shell script stopped looping.  And I went to
check (got about 3 within 4 minutes):
-rw-------    1 root     root     78811136 Feb 11 09:47 cbb20020211.0945
-rw-------    1 root     root     79515648 Feb 11 09:45 cbb20020211.0943
-rw-------    1 root     root     80248832 Feb 11 09:43 cbb20020211.0926

The following is from the cbb20020211.0945 core.  (I was thinking of renaming
EvalPacket, to EvilPacket ;).

(gdb) where
#0  EvalPacket (List=0x35313d74, mode=1634541612, p=0x815c7d0) at rules.c:3767
#1  0x80579a8 in Detect (p=0x815c7d0) at rules.c:3686
#2  0x8058f36 in Preprocess (p=0x815c7d0) at rules.c:3529
#3  0x807d00b in FlushStream (s=0x883f878, p=0xbfffeea0, direction=0)
    at spp_stream4.c:2831
#4  0x807b0ab in ReassembleStream4 (p=0xbfffeea0) at spp_stream4.c:1215
#5  0x8058f1a in Preprocess (p=0xbfffeea0) at rules.c:3523
#6  0x804c883 in ProcessPacket (user=0x0, pkthdr=0xbffff390, pkt=0x41699682 "")
    at snort.c:549
#7  0x8081301 in pcap_ring_recv (p=0x815a0f0, cnt=-1, 
    callback=0x804c754 <ProcessPacket>, user=0x0) at pcap-ring.c:280
#8  0x8082007 in pcap_loop (p=0x815a0f0, cnt=-1, 
    callback=0x804c754 <ProcessPacket>, user=0x0) at pcap.c:79
#9  0x804fbf2 in InterfaceThread (arg=0x0) at snort.c:1712
#10 0x804c745 in main (argc=19, argv=0xbffff534) at snort.c:479
#11 0x400b0b65 in __libc_start_main (main=0x804c0ac <main>, argc=19, 
    ubp_av=0xbffff534, init=0x804b61c <_init>, fini=0x80f641c <_fini>, 
    rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff52c)
    at ../sysdeps/generic/libc-start.c:111
(gdb) down
#0  EvalPacket (List=0x35313d74, mode=1634541612, p=0x815c7d0) at rules.c:3767
3767                        rtn_idx = List->TcpList;

The list structure pointer is text (51=t).  I think the mode is too (am ,)

(gdb)  print *p
$3 = {pkth = 0x816dc58, pkt = 0x816dc68 "", fddihdr = 0x0, fddisaps = 0x0, 
  fddisna = 0x0, fddiiparp = 0x0, fddiother = 0x0, trh = 0x0, trhllc = 0x0, 
  trhmr = 0x0, sllh = 0x0, pfh = 0x0, eh = 0x816dc68, vh = 0x0, ehllc = 0x0, 
  ehllcother = 0x0, ah = 0x0, iph = 0x816dd70, orig_iph = 0x0, 
  ip_options_len = 0, ip_options_data = 0x0, tcph = 0x816df00, 
  orig_tcph = 0x0, tcp_options_len = 0, tcp_options_data = 0x0, udph = 0x0, 
  orig_udph = 0x0, icmph = 0x0, orig_icmph = 0x0, ext = 0x0, 
  data = 0x816df14 "JÒUÖ\216­ºÒ[I\031\237\022!t\003ª®õ\206)\031*\016\206D|ª\217Z\006°îA\224Í\202rÛ®XâºZP\201Ø?P#nó 
b\222H+bRí\024\\ÁÀÙ\210\234à\022¤\016a\n¨ß)_¡È\022I#\r\200\ap¤ÈÚ¢\024*`ä\006È\020ÍÁ8úÞÿz\232«¿\027ǤáÇÝ\005ÀØÉ\030cì\210!WZp¯­%8Á4\t´T\207²Ø:¡Ô2\210sU$\eü8ð
 w?À\025Þ¬²Á\b\026ÈÔ¾\216Ò\2328\\³¶ÂV\230gÁ\023Æ^¤Â\a{¨\205 \230¹\020M£Â\204£BQ!U\031S\f"..., dsize = 1781, 
  frag_flag = 0 '\000', frag_offset = 0, mf = 0 '\000', df = 0 '\000', 
  rf = 0 '\000', sp = 80, dp = 1159, orig_sp = 0, orig_dp = 0, caplen = 0, 
  URI = {
    uri = 0x816df18 "\216­ºÒ[I\031\237\022!t\003ª®õ\206)\031*\016\206D|ª\217Z\006°îA\224Í\202rÛ®XâºZP\201Ø?P#nó 
b\222H+bRí\024\\ÁÀÙ\210\234à\022¤\016a\n¨ß)_¡È\022I#\r\200\ap¤ÈÚ¢\024*`ä\006È\020ÍÁ8úÞÿz\232«¿\027ǤáÇÝ\005ÀØÉ\030cì\210!WZp¯­%8Á4\t´T\207²Ø:¡Ô2\210sU$\eü8ð
 w?À\025Þ¬²Á\b\026ÈÔ¾\216Ò\2328\\³¶ÂV\230gÁ\023Æ^¤Â\a{¨\205 \230¹\020M£Â\204£BQ!U\031S\f4O ®"..., length = 30}, ssnptr 
= 0x0, 
  ip_options = {{code = 0 '\000', len = 0, data = 0x0} <repeats 40 times>}, 
  ip_option_count = 0, ip_lastopt_bad = 0 '\000', tcp_options = {{
      code = 0 '\000', len = 0, data = 0x0} <repeats 40 times>}, 
---Type <return> to continue, or q <return> to quit--- 
  tcp_option_count = 0, tcp_lastopt_bad = 0 '\000', csum_flags = 0 '\000', 
  packet_flags = 70}

What further information would be useful.

On Fri, Feb 01, 2002 at 09:01:42AM -0500, Martin Roesch wrote:
> Good morning,
>      I can see from the weblogs that 730 of you have downloaded
> 1.8.4-beta1, does anyone have any feedback or is it perfect in all ways
> and ready for release? :)
>
>      -Marty
>
>
> --
> Martin Roesch - Founder/CEO, Sourcefire Inc. - (410)552-6999
> Sourcefire: Professional Snort Sensor and Management Console appliances
> roesch () sourcefire com - http://www.sourcefire.com  
> Snort: Open Source Network IDS - http://www.snort.org
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

-- 
Phil Wood, cpw () lanl gov


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