Re: newbie quetsions (on how much Snort sucks)

[Dave Aitel <dave () immunitysec com>]

Martin Roesch wrote:

> Dave,
>
> I'm interested to know if you think Snort's stream reassmbler can't  
> handle your 1-byte segment test *by design* or as the result of a  
> *bug*?  

I had to assume it was by design. Is it a bug? My quicky look said that 
maybe it was because of the way the rules were written. IDS's are pretty 
much black box to me. The reason Snort features so highly in my emails 
and presentations is that it's the only one I can download and install. 
Obviously you aren't seeing lots of other vendors come out to say they 
pass this simple test, so a lot of companies have a lot of work to do. 
When lots of people have the same "bug" it's typically a design issue, I 
would guess. But this is not a Snort bug. This is a Snort-like bug, from 
what I can tell, with "Snort" playing the named place there because it 
was one of the first, and also the one everyone can get for free. (You 
can also get RealSecure's engine for free trial download, I believe, but 
most otheres are more difficult).

> Now, clearly it appears that you don't have anything  approaching 
> respect for my abilities as a developer of IDS technology  or for the 
> development effort that goes into Snort, but even assuming  that I'm 
> the worst C coder to ever fire up vi, if you spend more than a  
> nanosecond to think about it you'd probably come to the conclusion 
> that  this just might be unplanned behavior even if a complete fuckwit 
> like  myself implemented it.  

Well, a Snort box is useful for network monitoring and to look for 
worms, even if you aren't using it to look for hackers. Most CIOs really 
don't care about hackers, and do care a lot about worms, so I think in 
some senses, the marketplace doesn't differentiate. Likewise, a lot of 
the new technologies Sourcefire is working on are really cool.  I 
wouldn't run Snort on a non-grsec-ed box, but that's true for any 
complex parser written in C, and has nothing to do with the skills of 
the development team. One major benefit of Open Source is that you CAN 
run them on grsec-ed boxes.

> That being the case, if you were in the "open  source spirit" I would 
> probably expect to see a bug report someplace  like snort-users or 
> snort-devel or even in my inbox rather than blanket  statements like 
> "Snort's stream reassembler is horrible because it  failed my test 
> case" in forums like this one.

Aside from the presentation from October on Immunity's web site, the 
public announcement on this list, and the many announcements to the 
CANVAS mailing list dating back at least a year, I had to assume 
Sourcefire had done the basic QA. Not that Sourcefire should be singled 
out here. I think as people do more and more CRI tests, you'll see that 
lots of companies are designed to do extremely fast worm detection, 
rather than attacker detection. The penalty for a marginal increase in 
attacker detection is going to be lots of cash, since the development 
teams have to be ramped up quite a bit, and a lot of speed, since real 
parsing eats memory and CPU. And of course, that's all assuming the 
attacker doesn't get a copy of your IDS engine and do real analysis to 
evade you, which I haven't done, and don't plan to do.

> You could even take an  extra step and actually help out (really 
> getting into the open source  spirit now!) by making a simple pcap of 
> the failed session so that we  could do the debugging for you and let 
> you know what's going on if you  didn't want to take an hour and 
> figure it out yourself.

Everyone I've talked to has assumed it's a "feature" of the engine. I 
assumed you guys knew about it. I personally find the snort signature 
language nearly impossible to read, so I didn't push deeply into it.

> Now, just off the top of my head I suspect I know what the problem 
> is,  but really, couldn't you do anything more than just show up here 
> and  talk about how badly we suck?
It's my job to say when defenses are weak. That's all my company does. 
It's what people need to know when they're deploying defenses. The CRI 
is a reproducable test everyone can use for free, both customers and 
vendors. Neither I nor my company is taking money to bash or promote any 
particular IDS or IDS technology.

> As for the fragmented DCERPC records, you're right, you got us 
> there.   Interestingly enough, we have made allowances for just this 
> sort of  thing in Snort by building several APIs that allow you to 
> extend  Snort's functionality in case something like this comes along 
> that we  didn't think of when we first developed Snort.  In this 
> particular  case, I'd say we need to normalize the DCERPC calls which 
> would  indicate to me that a Snort DCERPC normalization preprocessor 
> would be  the appropriate route to solving this problem.  

Immunity doesn't sell a Snort-based product. If we did, we no doubt 
would have to go into Snort and build all of this. Realisitically it 
would make Snort a little bit faster, since it would be running one rule 
for each RPC bug, instead of six. There's a difference in solutions 
backed by companies that made the choice to invest in doing this and 
companies that didn't, and the CRI illustrates that decision. Immunity 
has donated lots of MSRPC code to the Open Source community, and you're 
free to use it, although I'd use the SAMBA-TNG code as it's more 
technically correct.

http://www.immunitysec.com/resources-freesoftware.shtml

> P.S. I've been working on a new stream reassembler since November  
> that'll be introduced to Snort RSN.  If you look at the new IP  
> defragmenter that I implemented which was checked into Snort CVS back  
> in November, you can probably get an idea where I'm headed with the 
> new  stream reassembler.

Is this even an IP-level flaw? I assumed it was somewhere else. It's 
funny that the major benefit of the Open Source development model claims 
is "lots of QA". 

Dave Aitel
Immunity, Inc.


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------