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.
--------------------------------------------------------------------------
