Date: Tue, 13 Sep 2005 23:23:53 -0400
From: purplebag <purplebag@...il.com>
To: "Ferguson, Justin (IARC)" <FergusonJ@...doe.gov>
Cc: Martin Roesch <roesch@...rcefire.com>,
	"snort-devel@...ts.sourceforge.net" <snort-devel@...ts.sourceforge.net>,
	"snort-users@...ts.sourceforge.net" <snort-users@...ts.sourceforge.net>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [Snort-users] Snort DoS Fallacies


good lord you fame mongering whores really need to get some skill. 

On 9/13/05, Ferguson, Justin (IARC) <FergusonJ@...doe.gov> wrote:
> Martin,
> 
> I would hardly call this "analysis", as I took the time to look through the
> code which obviously you guys originally did not do- as the report came
> across as this is only a problem if you are using -v, which as you stated is
> not true. As for whether the other tcp options can cause the same problem I
> am not sure, you are correct in that I did not go that far into it, however
> because the pointer was not checked, it feasibly *could* happen, providing
> there was no other checks done before it was called, seeing as I didn't see
> any such checks in the calling PrintTCPHeader(), then one would guess that
> it would be possible to cause the same issues with other options-- however
> no, I did not spend a lot of time figuring out the logistics of it, just
> that the null pointer wasn't checked for.

Personally I try to make sure I am actually looking at the right code
before I spout off. Then I take the time to verify what I believe.
This shit is simply foolish. Of course I never disclose what I find so
it doesn't matter for me.

<sn>

> 
> >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.
> [...]
> > 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.
> 
> While I will not disagree with you, I have seen this in several production
> environments. Regardless of whether someone should be doing this or not is
> beside the point, here is another execution path that could lead to the same
> result. You arguing that no one should be doing this is akin to DJB arguing
> that because people should be using ulimits that there isn't a bug in
> qmail-- the point still remains that there is/was a bug.

A DOS in a non critical component without any chance of remote code
execution is hardly worth this intellectual fart.

> 
> >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. :)
> 
>    snort/src/preprocessors/spp_frag3.c
> 2929 Frag3Rebuild()
>      [...]
> 3117 #ifdef DEBUG_FRAG3
>      [...]
> 3122     if (DEBUG_FRAG & GetDebugLevel())
> 3123     {
>      [...]
> 3126         PrintIPPkt(stdout, defrag_pkt->iph->ip_proto, defrag_pkt);
>      [...]
> 3129     }
> 3130 #endif
>       [...]
> 3133         PrintIPPkt(stdout, defrag_pkt->iph->ip_proto, defrag_pkt);
> 
> Re-read the code snippet, developer. Notice the closing curly bracket
> follwed by the #endif. You have two identical pieces of code, one is wrapped
> in a #ifdef and a if (DEBUG ...) and the other isn't. So, one is only there
> if debugging is enabled, the other exists in the preprocessor regardless.


Maybe I got my CVS checkout from the wrong server or something but I
can't find more than one call in the snapshot I have

...snort-2.4.0/src/preprocessors $ grep PrintIPPkt spp_frag3.c 
        PrintIPPkt(stdout, defrag_pkt->iph->ip_proto, defrag_pkt);

"Re-read the code snippet, developer." - Seems to me that perhaps you
get some lessons in music or something because your mad hax0r
d3ve10p3r skills are a lacking. You are either really foolish or
without shame to have made a statement like that. If your mother
taught you anything I would have hoped it be respect. Where is your
respect? Your mother would be ashamed.

Ultimately It seems that he was right and you were wrong so perhaps
you need to check your attitude and code at the door.

> 
> >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.
> 
> This may be the case, and I won't argue the point as I didn't research into
> the feasibility of whether it was possible to cause a null pointer there,
> just that it *could* happen, as I said.

So what you are saying is you are full of shit. I actually had to read
the fucking code instead of fucking because you have something fucked
up. ( I wanted to get another fuck in there so here it is )

> 
> >Wow, we did almost as well as you!!
> 
> My line was originally incorrect as I was under the impression that this was
> the result of an internal audit of some sort, whereas this was the result of
> someone fuzzing snort.
> 

Again we see that you fail to read and assume. We all know what assume
is don't we?

> 
> >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.
> 
> Thank you for adding to my point. This makes what 3 possible routes of
> execution + the -v route for a total of 4 without debugging, and 6 if
> debugging was to be enabled. Still quite a long ways from the 'only if you
> are using -v'.

So basically your point is you don't have a clue, are a superfluous
twit, incompetent fame whore, and chump?

Perhaps you just sit in your chair masturbating to captured porn all
day and that is why you didn't have time to verify your specious shit.
Give me your address and I will send you the lapjuicer so you can at
least make a profit when you and your buddies get together.

http://3eyes.co.uk/views/public/?doc=Lapjuicer

Just my personal grumpy thoughts of the moment.


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