[Snort-devel] Crash in AC SparseBands
mnorton at ...402...
Mon Dec 4 14:49:55 EST 2006
There was a bug in ac-sparsebands in the 2.6.0 series, that could cause
a segv. It is fixed in the 2.6.1 series. Also, in the 2.6.1 series you
should use the 'ac-bnfa' search method. It uses very little memory
compared to all of the previous 'ac' methods, and is about 95-100% of
the same speed. This will become our default soon.
Matthew Hall wrote:
> Hi Snort Devs,
> We've been running snort (220.127.116.11), 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,
> n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:1933
> #1 0x080ce6f1 in acsmSearch2 (acsm=0xc33f038,
> n=1460, Match=0x80703db <otnx_match>, data=0x81067e0) at acsmx2.c:2240
> #2 0x080c6821 in mpseSearch (pvoid=0xc1bdc98,
> 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).
> Matthew Hall
> Security Engineer
> ECSC Ltd
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
Marc Norton Snort Team Lead
More information about the Snort-devel