[Snort-devel] Version 1.7-beta3 segmentation fault in checksum.c

Phil Wood cpw at ...86...
Sat Nov 18 01:43:58 EST 2000


On Fri, Nov 17, 2000 at 11:33:53PM -0500, Christopher Cramer wrote:
> 
> Philip,
> 
> This is a known problem that actually resides in the IP decoding
> engine.  Certain types of corrupt packets will basically cause snort to
> believe that the packet length is ~2^32.  When the checksum routines try
> to parse this they eventually access a memory address not owned by snort.   
> I was going to try to fix the DecodeIP routine this week, but got
> sidetracked.
> 
> The fix should be available soon, maybe by Monday.

Ok! Then I didn't need to go to all this trouble ;(

Here is what I worked up this evening.

#4  0x804fd46 in DecodeIP (pkt=0x4028e690 "E", len=56, p=0xbffff160)
0x4028e690:     0x38000045      0x0000abb7      0x07ae01ff      0x030110c0
0x4028e6a0:     0x1300eb94      0x74ef0303      0x00000000      0x10000045
0x4028e6b0:     0x00003bda      0x7c171173      0x1300eb94      0x030110c0
0x4028e6c0:     0x9804f408      0x00001000
    at decode.c:726
            case IPPROTO_ICMP:
                pc.icmp++;
       726         DecodeICMP(pkt + hlen, ip_len, p);

#3  0x8050029 in DecodeICMP (pkt=0x4028e6a4 "\003\003ït", len=36, p=0xbffff160)
0x4028e6a4:     0x74ef0303      0x00000000      0x10000045     0x00003bda
                0x7c171173      0x1300eb94      0x030110c0     0x9804f408
                0x00001000
    at decode.co1042
                bzero((char *)&orig_p, sizeof(Packet));
                orig_p.caplen = len - 8;
      1042      DecodeIP(pkt + 8, orig_p.caplen, &orig_p);

#2  0x804fd26 in DecodeIP (pkt=0x4028e6ac "E", len=28, p=0xbfffeca0)

                  |||| This looks weird to me.  Like maybe the source of
                  |||| this icmp unreachable packet did a byte swap (ntoh)
                  |||| in place and then found the port number to be whacko
                  |||| and stuffed the requisite header and 64 bits into
                  |||| the icmp data portion for us to decode. *(see postscript)
                  |||| How can you have only 16 bytes in a 20 byte header!
                  VVVV 
0x4028e6ac:     0x10000045     0x00003bda      0x7c171173      0x1300eb94
                0x030110c0     0x9804f408      0x00001000
    at decode.c:720
            case IPPROTO_UDP:
                pc.udp++; **** this is inflating udp count (counting packets
                               to unreachable destinations twice!)
647:   hlen = p->iph->ip_hlen << 2;  [20]
682:   ip_len -= hlen;       -4      [FFFFFFFC or 4294967292]           

      720       DecodeUDP(pkt + hlen, ip_len, p);

#1  0x804feea in DecodeUDP (pkt=0x4028e6c0 "\bô\004\230", len=4294967292, p=0xbfffeca0) 
0x4028e6c0:     0x9804f408      0x00001000
    at decode.c:918

    918     csum = checksum((u_short *)&ph, 12, (u_short *)(p->udph), len);

#0  0x80627f6 in checksum (b1=0xbfffec20, len1=12, b2=0x40352000, 
    len2=4294967292) at checksum.c:63 (and here is where we take a ride
    on the wild side.)

* As serendipity would have it, this morning a colleague came in with
  a problem.  Our linux 2.4.10 stateful firewall was dropping an icmp
  port unreachable (the result of a traceroute from a Solaris box) from
  a "netapp" box.  This was remarkable since, when we did the same thing
  from a linux box the icmp unreachable made it through with no problem.
  My theory after analyzing the packet headers is that the netapp was
  munging the Flags/Fragment Offset field, but was doing it
  in place and then using the resultant header and 64 bits in the icmp
  unreachable.  Solaris sets the DF bit.  When the packet went out that
  16 bit field was correct 4000, when it came back it was 0040.  
  The ip header was corrupt (bogus offset) in the data portion of the
  icmp unreachable and thus, our firewall correctly dropped the sucker.
  
  And now, I'm analyzing this all in the space of 8 hours.

PS: is there a place I can get the list of known problems?

> 
> -Chris
> 
> ----------------------------------------------------------------------
> Dr. Christopher E. Cramer
> Assistant Research Professor
> Duke University, Department of Electrical and Computer Engineering
> 114 Hudson Hall, Box 90291, Durham, NC  27708-0291
> PH:  919-660-5248     FAX:  919-660-5293     email:  cec at ...56...
> 
> 
> On Fri, 17 Nov 2000, C. Philip Wood wrote:
> 
> > 
> > Stop the pressess, your snort may die as did mine:
> > 
> > gdb bin/snort core
> > GNU gdb 19990928
> > Copyright 1998 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i686-pc-linux-gnu"...
> > 
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /lib/libnsl.so.1...done.
> > Reading symbols from /lib/libm.so.6...done.
> > Reading symbols from /usr/lib/libmysqlclient.so.6...done.
> > Reading symbols from /lib/libc.so.6...done.
> > Reading symbols from /usr/lib/libz.so.1...done.
> > Reading symbols from /lib/libcrypt.so.1...done.
> > Reading symbols from /lib/ld-linux.so.2...done.
> > Reading symbols from /lib/libnss_db.so.2...done.
> > Reading symbols from /lib/libdb.so.3...done.
> > Reading symbols from /lib/libnss_files.so.2...done.
> > Reading symbols from /lib/libnss_dns.so.2...done.
> > Reading symbols from /lib/libresolv.so.2...done.
> > #0  0x80627f6 in checksum (b1=0xbfffec20, len1=12, b2=0x40352000, 
> > ---Type <return> to continue, or q <return> to quit---
> >     len2=4294967292) at checksum.c:63
> > 63                  sum += *((u_int16_t*)b2 ++);
> > (gdb) where
> > #0  0x80627f6 in checksum (b1=0xbfffec20, len1=12, b2=0x40352000, 
> >     len2=4294967292) at checksum.c:63
> > #1  0x804feea in DecodeUDP (pkt=0x402576c0 "\006 \004\230", len=4294967292, 
> >     p=0xbfffeca0) at decode.c:918
> > #2  0x804fd26 in DecodeIP (pkt=0x402576ac "E", len=28, p=0xbfffeca0)
> >     at decode.c:720
> > #3  0x8050029 in DecodeICMP (pkt=0x402576a4 "\003\003ñÈ", len=36, p=0xbffff160)
> >     at decode.c:1042
> > #4  0x804fd46 in DecodeIP (pkt=0x40257690 "E", len=56, p=0xbffff160)
> >     at decode.c:726
> > #5  0x804fb8e in DecodeFDDIPkt (p=0xbffff160, pkthdr=0xbffff604, 
> >     pkt=0x4025767b "P") at decode.c:390
> > #6  0x804aa49 in ProcessPacket (user=0x0, pkthdr=0xbffff604, 
> >     pkt=0x4025767b "P") at snort.c:466
> > #7  0x8062b98 in packet_ring_recv ()
> > #8  0x8062edf in pcap_read ()
> > #9  0x8063b63 in pcap_loop ()
> > #10 0x804cb55 in InterfaceThread (arg=0x0) at snort.c:1359
> > #11 0x804aa18 in main (argc=16, argv=0xbffff7f4) at snort.c:449
> > 
> > pkt is the following in DecodeIP at decode.c:720
> > 0x4028e6ac:     0x10000045
> > 0x4028e6b0:     0x00003bda
> > 0x4028e6b4:     0x7c171173
> > 0x4028e6b8:     0x1300eb94
> > 0x4028e6bc:     0x030110c0
> > 0x4028e6c0:     0x9804f408
> > 0x4028e6c4:     0x00001000
> > 0x4028e6c8:     0x1f041300
> > 0x4028e6cc:     0x23222120
> > 0x4028e6d0:     0x27262524
> > 0x4028e6d4:     0x2b2a2928
> > 0x4028e6d8:     0x2f2e2d2c
> > 0x4028e6dc:     0x33323130
> > 0x4028e6e0:     0x37363534
> > 0x4028e6e4:     0x00000000
> > 0x4028e6e8:     0x00000000
> > 0x4028e6ec:     0x00000000
> > 0x4028e6f0:     0x00000000
> > 0x4028e6f4:     0x00000000
> > 0x4028e6f8:     0x00000000
> > 0x4028e6fc:     0x00000000
> > 0x4028e700:     0x00000000
> > 0x4028e704:     0x00000000
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/mailman/listinfo/snort-devel
> > 

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




More information about the Snort-devel mailing list