Date: Tue, 13 Sep 2005 22:29:48 -0400
From: Richard Harman <snort@...hardharman.com>
To: Martin Roesch <roesch@...rcefire.com>,
	"'snort-devel@...ts.sourceforge.net'" <snort-devel@...ts.sourceforge.net>
Cc: "'bugtraq@...urityfocus.com'" <bugtraq@...urityfocus.com>
Subject: Re: [Snort-users] Snort DoS Fallacies (3 forged mails "from" marty?)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wow, What's up with all the mail forgery to the list?  Someone sure
likes bouncing/redistributing mail as Marty.  Good thing Marty uses PGP.

Richard

1)
- -----
Received: from eagle.megaweb.co.za ([196.22.235.76] helo=megaweb.biz)
	by mail.sourceforge.net with esmtp (Exim 4.44)
	id 1EFKeo-0005ql-Cc; Tue, 13 Sep 2005 16:57:47 -0700
Received: from mail pickup service by megaweb.biz with Microsoft SMTPSVC;
	 Wed, 14 Sep 2005 02:01:18 +0200
Message-ID: <000001c5b8bf$531904a0$020c0c0a@...online.internal>
From: "Martin Roesch" <roesch@...rcefire.com>
Subject: Re: [Snort-users] Snort DoS Fallacies
- ------

2)
- ------
Received: from 220-245-105-244.static.tpgi.com.au ([220.245.105.244]
helo=sbsonline.com.au)
	by mail.sourceforge.net with esmtp (Exim 4.44)
	id 1EFKgI-00063F-04; Tue, 13 Sep 2005 16:59:19 -0700
Received: from mail pickup service by sbsonline.com.au with Microsoft
SMTPSVC;
	 Wed, 14 Sep 2005 10:00:32 +1000
Message-ID: <000001c5b8bf$531904a0$020c0c0a@...online.internal>
From: "Martin Roesch" <roesch@...rcefire.com>
Subject: Re: [Snort-users] Snort DoS Fallacies
- ------

3)
- ------
Received: from relayfix.tiscali.de ([62.27.33.188])
	by mail.sourceforge.net with esmtp (Exim 4.44)
	id 1EFKal-0005IC-Fz; Tue, 13 Sep 2005 16:53:37 -0700
Received: from mail1.mervisoft.de (p54A9EB31.dip.t-dialin.net
[84.169.235.49])
	by relayfix.tiscali.de (Postfix) with ESMTP
	id 60855505747; Wed, 14 Sep 2005 01:53:28 +0200 (CEST)
Received: from mail pickup service by mail1.mervisoft.de with Microsoft
SMTPSVC;
	 Wed, 14 Sep 2005 01:31:04 +0200
Delivered-To: info@...visoft.de
- ------

Martin Roesch wrote:
> 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
> 
> 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJ4sb3rKdb192Vz8RAoSBAKCu5DHE7QzNm49DNR7I0HfFU3O2yQCgrBxC
vEv3T5DJyYufy150cBgXCpc=
=Waha
-----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

Powered by blists - more mailing lists