<<< Date Index >>>     <<< Thread Index >>>

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