Re: [Snort-users] Snort DoS Fallacies
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, let's see if we can kill the "analysis" and random speculation
dead with this thread.
Comments inline:
On Sep 13, 2005, at 10:47 AM, Ferguson, Justin (IARC) wrote:
First, if we are using the option -A fast:
snort/src/output-plugins/spo_alert_fast.c
134 AlertFast()
[...]
146 if(msg != NULL)
147 {
[...]
208 if(p && data->packet_flag)
209 {
210 fputc('\n', data->file);
211
212 if(p->iph)
213 PrintIPPkt(data->file, p->iph->ip_proto, p);
That's not right. This will only happen if you give Snort a config
directive in the snort.conf file with a specific argument. You
didn't bother to check where the data->packet_flag is set, when you
specify fast as a command line option the alerting plugin is
automatically loaded with a NULL argument string. Here's the config
line you need to make it happen:
output alert_fast: packet
I've never seen anyone configure their system like that, although I'm
sure someone must have or else the code wouldn't be there (it
basically recreates "Full" mode and loses purpose of "Fast" mode).
Regardless, it's not the default and not accessible from the command
line.
Second, if we are logging in ASCII mode (a lot of people):
If "a lot of people" are logging in ASCII mode then nobody is reading
the docs, the books, the mailing list archives or thinking about how
ASCII mode logging works with real file systems. If you do this
there's another DoS waiting for you in your future, the one where the
ASCII logging system exhausts your filesystem's inodes. If you read
the mailing list archives from the last several years you'll see it
come up from time to time, I think there's even a FAQ entry for it,
not to mention info in the various config guides on not DoS'ing
yourself. For the record, NO PRODUCTION SNORT DEPLOYMENT SHOULD EVER
(EVER!!!) RUN WITH ASCII LOGGING!!! Everyone should be using
unified, database or binary (pcap) logging for production sensors,
period end of story. ASCII logging is suitable only for testing and
lab environments, that's it.
Also, in the frag3 preprocessor, also I'm not sure what the point
of defining DEBUG_FRAG3 at compile time would be (at least in this
code segment), as the execution flow is exactly the same:
It can also be called in the stream4 preprocessor, if a few
debugging conditions are met:
That's debug code there, we (developers) only enable that when we're
testing stuff out. If you turn on all Snort's debug code you aren't
running an IDS anymore, you're running chargen. :) It's in there for
when developers need to "lift the hood" on Snort to figure out what's
happening behind the scenes. No production sensor should ever be
deployed with debug code enabled (unless you're debugging code, but
then that's no longer a production sensor, QED).
Additionally, as the second part of the misrepresentation of data,
there is several bugs in PrintTCPOptions(), which is apparent by
the changes they made-- these include nearly all of the TCP
options, not just SACK. These include the following options:
TCPOPT_MAXSEG, TCPOPT_WSCALE, TCPOPT_ECHO, TCPOPT_ECHOREPLY,
TCPOPT_TIMESTAMP, TCPOPT_CC, TCPOPT_CCNEW, TCPOPT_CCECHO, and _any_
unrecognized or invalid option.
Actually, if you had done the research you would have seen that this
DoS condition doesn't work for:
TCPOPT_MAXSEG
TCPOPT_WSCALE
TCPOPT_ECHO
TCPOPT_ECHOREPLY
TCPOPT_TIMESTAMP
TCPOPT_CC
TCPOPT_CCNEW
TCPOPT_CCECHO
or _any_ unrecognized or invalid option.
While we were cleaning up the code for the SACK problem we thought
we'd make sure that there could never be another NULL ptr dereference
in that code. Whether or not these are "bugs" (as you term them) is
open to interpretation because they don't look like you can exercise
them, but they certainly weren't as solid as they could have been so
we cleaned them up.
However, the snort team did say one thing correctly, and that these
all are NULL pointer dereferences, and therefore only a DoS and not
exploitable to run arbitrary code.
Wow, we did almost as well as you!!
BTW, you missed that we also call PrintTCPHeader in spo_alert_full.c,
which is actually done in the default config case, so this is
something you might want to worry about if you're using full alerting
for whatever reason. For the record, the recommended alerting modes
for a production sensor are unified, syslog or database.
I *strongly* recommend that people use unified logging/alerting for
the foreseeable future, this is The Right Way (and the high
performance way) to run a Snort sensor.
So, to summarize, there's an additional problem if you're using ASCII
mode logging, but if you've been running Snort for any time you
should know never to do that on a production sensor. There is an
actual real live issue if you run with Full-mode alerting, but you
should typically be using a more robust alerting mode for production
sensors anyway. If you're the one person on the planet that's
running Fast-mode alerting with the 'packet' config option turned on,
you should probably just switch to Full and get it over with since
they're effectively the same thing. There are no additional TCP
Options processing that have this issue at this time that I'm aware
of, if anyone knows otherwise please feel free to submit a report to
me or snort-team@xxxxxxxxxxxxxxx
-Marty
- --
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Discover. Determine. Defend.
roesch@xxxxxxxxxxxxxx - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDJ0Zyqj0FAQQ3KOARAoNBAJ9DtbuaxaizhcID7ohzqUBYRifI1ACeKNig
IwQdRGFcyy5+iYw27fyigHI=
=a1/3
-----END PGP SIGNATURE-----