[Snort-devel] Crash in AC SparseBands

Matthew Hall lists at ...1808...
Mon Dec 4 12:35:33 EST 2006


Hi Snort Devs,

We've been running snort (2.6.0.2), with the 'ac-sparsebands' config
detection type and have run into a few crashes (SEGV).

A little info about the box - it has 2 snort daemons running side by
side on a single, separate (gigabit) interface each. Though it usually
only sees around 2Mbps we've seen peaks at ~45Mbps occasionally, and are
running with PCAP_FRAMES=max. It's a pretty beefy box so load hardly
reaches 1.0, sitting around 0.5 on a normal day.

I've got snort running in debug mode under gdb (under screen, and it's
still open if you need me to prod the stack); backtrace follows.

(gdb) bt
#0  0x080cde76 in acsmSearchSparseDFA (acsm=0xc33f038,
    Tx=0x98a8a70
"\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:1933
#1  0x080ce6f1 in acsmSearch2 (acsm=0xc33f038,
    Tx=0x98a8a70
"\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:2240
#2  0x080c6821 in mpseSearch (pvoid=0xc1bdc98,
    T=0x98a8a70
"\uffff`\uffff\017\n\uffff\uffff4L\uffffc\u036e\033\uffff\uffff\020c\uffffHa\022\227(?Oy\uffff\uffff]\u07e2\036\032Gn\uffff",
    n=1460, action=0x80703db <otnx_match>, data=0x81067e0) at mpse.c:303
#3  0x08070eb3 in fpEvalHeaderSW (port_group=0xb52d7f0, p=0xbfa00f58,
    check_ports=1) at fpdetect.c:1385
#4  0x080711ea in fpEvalHeaderTcp (p=0xbfa00f58) at fpdetect.c:1558
#5  0x080714a3 in fpEvalPacket (p=0xbfa00f58) at fpdetect.c:1731
#6  0x0806a275 in Detect (p=0xbfa00f58) at detect.c:480
#7  0x08069c9b in Preprocess (p=0xbfa00f58) at detect.c:157
#8  0x08061cdd in ProcessPacket (user=0x0, pkthdr=0xbfa01328,
    pkt=0x98a8a3a "", ft=0x0) at snort.c:1291
#9  0x08061aad in PcapProcessPacket (user=0x0, pkthdr=0xbfa01328,
    pkt=0x98a8a3a "") at snort.c:1202
#10 0xb7d67970 in pcap_platform_finddevs () from /usr/lib/libpcap.so.0.8.3
#11 0xb7d69107 in pcap_dispatch () from /usr/lib/libpcap.so.0.8.3
#12 0x0806401e in InterfaceThread (arg=0x0) at snort.c:2618
#13 0x08061632 in SnortMain (argc=16, argv=0xbfa01524) at snort.c:1019
#14 0x08060bf1 in main (argc=16, argv=0xbfa01524) at snort.c:345



I've not tried 2.6.1(.1) yet - but am happy to if any devs can say there
were bugs in the AC implementation which might've been fixed...


I'm not sure if this is related - but we've had a few alerts generated
on the interface the debug snort is running under which seem to be
corrupted (all of these alerts come from 'snort_decoder').
When converting the unified log to pcap via barnyard, wireshark/ethereal
sees that the tcp options are offset by 12bytes; ie. wireshark
recognises the end of the tcp header as the start of some tcp options,
but it is actually the top of the data portion of the packet.
I'm not sure if this is a wireshark bug or not, but I can't find similar
packets when pulling straight from the wire, and have only seen this on
packets being processed through snort into a unified log (and then to
pcap via barnyard).


Cheers,
Matthew Hall
Security Engineer
ECSC Ltd





More information about the Snort-devel mailing list