[Snort-devel] Whee, Coredump
Roy S. Rapoport
snort-devel at ...2006...
Sat May 31 14:22:07 EDT 2003
On Sat, May 31, 2003 at 09:30:15AM -0400, Brian wrote:
> On Sat, May 31, 2003 at 03:02:28AM -0700, Roy S. Rapoport wrote:
> > Been working on getting SnortCenter to play nice with Snort 2.0. At
> > this point, SnortCenter has managed to create a config file for snort
> > that causes it to segfault and dump core. I'm guessing this is
> > unexpectedly bad.
> > The config file is about 500K, so I figured it'd be impolite to mail it.
> > It's available at http://www.inorganic.org/~rsr/bad_snort_config.txt
> SnortCenter is generating some bad rules.
> line 501 is:
> alert tcp $EXTERNAL_NET any -> $HOME_NET 111 ( sid: 2093; rev: 2; msg: "RPC portmap proxy integer overflow attempt TCP"; flow: to_server,established; content: "|00 00 00 00|"; offset: 8; depth: 4; content: "|00 01 86 A0 00|"; offset: 16; depth: 5; content: "|00 00 00 05|"; distance: 3; within: 4; byte_jump:4,4,relati; byte_test:4,>,2048,12,relative; reference: cve,CAN-2003-0028; reference: bugtraq,7123; classtype: rpc-portmap-decode;)
> Note the first byte_jump keyword.
> snort 2.0.0 doesn't coredump for me, but it does give me the error
> ERROR: bad_snort_config.txt(501): unknown modifier "(null)"
Right. That's definitely the cause of the segfault:
#0 0xff132fb0 in strlen () from /usr/lib/libc.so.1
#1 0xff184f08 in _doprnt () from /usr/lib/libc.so.1
#2 0xff186eec in vsnprintf () from /usr/lib/libc.so.1
#3 0x0003fa88 in FatalError (format=0xb93b8 "%s(%d): unknown modifier
\"%s\"\n") at util.c:665
#4 0x0006cc80 in ByteJumpParse (data=0x34a200 " 4,4,relati",
idx=0x34a218, otn=0x34bc78) at sp_byte_jump.c:258
#5 0x0006c834 in ByteJumpInit (data=0x34a200 " 4,4,relati",
otn=0x34bc78, protocol=6) at sp_byte_jump.c:144
#6 0x0002ebdc in ParseRuleOptions (
rule=0xffbfd370 "alert tcp any any -> any 111 ( sid: 2093; rev: 2;
msg: \"RPC portmap proxy integer overflow attempt TCP\"; flow:
to_server,established; content: \"|00 00 00 00|\"; offset: 8; depth: 4;
content: \"|00 01 86"..., rule_type=2, protocol=6) at parser.c:1713
#7 0x0002c684 in ParseRule (rule_file=0x171e20,
prule=0xffbff490 "alert tcp $EXTERNAL_NET any -> $HOME_NET 111 (
sid: 2093; rev: 2; msg: \"RPC portmap proxy integer overflow attempt
TCP\"; flow: to_server,established; content: \"|00 00 00 00|\"; offset:
8; depth: 4; con"..., inclevel=0) at parser.c:709
#8 0x0002b1ac in ParseRulesFile (file=0x236278
#9 0x00037cdc in SnortMain (argc=4, argv=0xffbffa04) at snort.c:461
#10 0x00037318 in main (argc=4, argv=0xffbffa04) at snort.c:166
I found two bugs with SnortCenter that I'm working on fixing:
A) As shipped, RC1 does not have a column for content for byte_jump; I
fixed this bug by adding a varchar(10) column, but that was too short
(hence "4,4,relativ"). I've changed that to varchar(40) which, based on
the manual, _seems_ like it'll be enough;
B) RC1 does not cope well with multiple content statements that have
byte_jump parameters. Not too surprising -- until last night, my
version wasn't coping well with the same situation as it relates to
So obviously, that's not Snort's fault. So far, Snort's a champion (not
to mention that YOU GUYS COMMENT CODE. Sorry, frustrated -- have you
seen the PHP code for SnortCenter?). Anyway, I'm *guessing* that
segfaulting is still bad behavior when it comes to bad code (and
obviously, it doesn't do it for you).
Last time I dealt with something like this (also, similarly, a program
segfaulting on bad config file data) was with BIND, and there was a
formal bug tracking system to which I could submit a bug. Is there
something similar for Snort, or have I done all I can to give reasonable
Thanks, by the way, for the help narrowing the problem down.
More information about the Snort-devel