Message-ID: <000001c5b8bb$35879400$86c8a8c0@MervaSBS2003.local>
Date: Wed, 14 Sep 2005 01:31:04 +0200
From: "Martin Roesch" <roesch@...rcefire.com>
To: <kbo@...ayfix.tiscali.de>
Cc: <snort-devel@...ts.sourceforge.net>,
	<snort-users@...ts.sourceforge.net>, <bugtraq@...urityfocus.com>
Subject: Re: 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@...rcefire.com.

      -Marty

- --
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Discover.  Determine.  Defend.
roesch@...rcefire.com - 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-----




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Snort-users mailing list
Snort-users@...ts.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Powered by blists - more mailing lists