|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: Fooling NIDS
From: Martin Roesch (roesch
MD.PRESTIGE.NET)Date: Tue Dec 05 2000 - 15:48:37 CST
- Next message: Stephen MacDonald: "Re: Switched environment NIDS"
- Previous message: Crist Clark: "Re: Fooling NIDS"
- In reply to: Crist Clark: "Re: Fooling NIDS"
- Next in thread: Crist Clark: "Re: Fooling NIDS"
- Next in thread: Jon Gary: "Re: Fooling NIDS"
- Reply: Martin Roesch: "Re: Fooling NIDS"
- Reply: Crist Clark: "Re: Fooling NIDS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Doh! Digging through my inbox I have indeed found your messages. Profuse
apologies for not getting back to you sooner. My only excuse is that I've
been sick (and traveling on and off) for the past three weeks and I've been
having a tough time keeping up with the demands of Snort. I'm finally feeling
better in the past couple of days and going through my inbox as much as
possible trying to get through the 375 messages that I've allowed to
accumulate. At least I don't have to travel anytime soon. :)
Anyway, this is an interesting case. Without seeing a core dump it looks like
you've got straight TCP traffic here crashing Snort. Judging by the line you
say its crashing on, probably one of the packet pointers is nulled out and
it's failing on the dereference. If this is just plain Snort 1.6.3, you
should probably try out version 1.6.3-patch2 which is available on the
downloads page of www.snort.org or (more easily)
http://snort.sourceforge.net.
If you want to patch your existing code, you can add this check right before
the if statement you site in sp_tcp_seq_check.c:
if((p == NULL) || (p->tcph == NULL))
{
return 0;
}
Version 1.6.3 had a problem where you could get packets with NULL pointers
into the detection engine where they would potentially be dereferenced by any
of the plugins, which generally expect the packet pointers to be good when
they run.
Thanks for the bug report, sorry for the delay in responding!
-Marty
Crist Clark wrote:
>
> Martin Roesch wrote:
> >
> > Really?! Can you provide more information about what was causing the Snort
> > crashes?
>
> Umm, well, I sent you an email two weeks ago with full details and another
> brief one earlier this week. I never heard anything. I joined the snort-devel
> list and was going to bring it up there after I got a feel for the list.
>
> I have not had the chance to dig into exactly what is happening in Snort.
> But I did narrow it down to a very reproducible crash. It happened
> with Snort 1.6.3 built from the ports in FreeBSD 4-STABLE and on a fully
> patched OpenBSD 2.7 system with a vanilla Snort build. I was using Max's
> arachNIDS rule set. The crash did not occur with the ruleset distributed
> with Snort.
>
> The following attack would send Snort belly up (I think you smart kids
> on FOCUS-IDS can figure out what this format means),
>
> get_phf_syn_ack_get () {
> $IWU $src $dst $nb $ttl "\
> 4500 003c 22af 4000 4006 c2d7 0101 0101 \
> 0202 0202 0662 0050 ed75 49e4 0000 0000 \
> a002 7d78 b73e 0000 0204 05b4 0402 080a \
> 00ec 7f22 0000 0000 0103 0300"
> $IWU $src $dst $nb $ttl "\
> 4500 0034 22b0 4000 4006 c2de 0101 0101 \
> 0202 0202 0662 0050 ed75 49e5 fce2 41ce \
> 8010 7d78 9e35 0000 0101 080a 00ec 7f22 \
> 0b61 fdab"
> $IWU $src $dst $nb $ttl "\
> 4500 004f 22ff 4000 4006 c274 0101 0101 \
> 0202 0202 0667 0050 54a6 4c48 65f5 9f89 \
> 8018 7d78 cdaf 0000 0101 080a 00ef 06b0 \
> 0b64 8537 4745 5420 2f63 6769 2d62 696e \
> 2f70 6866 2048 5454 502f 312e 300a 0a"
> }
>
> At the arachNIDS rule,
>
> alert TCP $EXTERNAL :1024 -> $INTERNAL any (msg:"IDS252/ddos-shaft-synflood-incoming"; seq: 674711609; flags: S;)
>
> At the following point in Snort,
>
> ...
> int CheckTcpSeqEq(Packet *p, struct _OptTreeNode *otn, OptFpList *fp_list)
> {
> if (((TcpSeqCheckData *)otn->ds_list[PLUGIN_TCP_ACK_CHECK])->tcp_seq == nto\
> hl(p->tcph->th_seq))
> {
> ...
>
> Which is code in sp_tcp_seq_check.c. This specifically was the data
> from a seg-fault on OpenBSD.
>
> Since I wanted to make sure it was not a configuration or compilation
> error on my part before I did something like post on securityfocus.com
> list, I meant to do some more analysis first. But since it came up...
> --
> Crist J. Clark Network Security Engineer
> crist.clark
globalstar.com Globalstar, L.P.
> (408) 933-4387 FAX: (408) 933-4926
-- Martin Roesch roeschmd.prestige.net http://www.snort.org
- Next message: Stephen MacDonald: "Re: Switched environment NIDS"
- Previous message: Crist Clark: "Re: Fooling NIDS"
- In reply to: Crist Clark: "Re: Fooling NIDS"
- Next in thread: Crist Clark: "Re: Fooling NIDS"
- Next in thread: Jon Gary: "Re: Fooling NIDS"
- Reply: Martin Roesch: "Re: Fooling NIDS"
- Reply: Crist Clark: "Re: Fooling NIDS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]