Re: Snort 2.9.0.1 Now Available

[Russ Combs <rcombs () sourcefire com>]

Correction on where to send / how to file bugs and other issues ... please
see the info here:

http://www.snort.org/community/contact-us/.

On Tue, Nov 9, 2010 at 1:51 PM, Russ Combs <rcombs () sourcefire com> wrote:

> Eoin has provided a pcap from the blog referenced earlier in the thread and
> we are able to recreate the issue.  This pcap differs from the pcap I
> crafted with respect to ack placement which is why I was not able to
> reproduce the results earlier.  I've opened a bug on it and will try to get
> this into the next release.
>
> The bug is in Snort's stream5 preprocessor.  Http_inspect depends on
> stream5 to reassemble the TCP payloads and in this case the stream was
> flushed prematurely.  This issue predates Snort 2.9.0.
>
> For the record, the Snort Team was able to reproduce and identify the
> problem within minutes of receiving the problematic pcap.  It had earlier
> been sent only to research () sourcefire com.  Please copy
> snort-team () sourcefire com and/or snort-devel () lists sourceforge net on such
> emails in the future to help avoid a similar delay.
>
> Thanks
> Russ
>
> From Eoin:
>
> This is an older one I had sent in to research () sourcefire com. This is the
> one that is the same as the blog posting, sorry it took so long to dig up.
>
> -- Eoin
>
> -------- Original Message --------  Subject: http_header and split packets  Date:
> Fri, 17 Sep 2010 18:12:40 +0000  From: Eoin Miller
> <eoin.miller () trojanedbinaries com> <eoin.miller () trojanedbinaries com>  To:
> research () sourcefire com
>
> Not really sure if there is much you guys can do for this or not, but when
> we see an HTTP request being split across two packets (generally due to an
> extremely long URI and IE's insanely long list of "Accept:" headers),
> Snort's http_inspect doesn't get all the content from the multiple packets
> into the buffers which leads to some false negatives (we had about a
> thousand false negatives last night due to this issue). Since the URI is
> very long and IE puts the "Host: " header near the end of the request, it
> becomes easy to circumvent this type of detection against IE browsers that
> is based upon the HTTP host header unless you end up using jumbo frames or
> something. The attached PCAP is a sample of traffic we are unable to alert
> on with the below sigs for tracking known names of malvertising servers:
> <snip>
>
>
>
> On Mon, Nov 8, 2010 at 3:11 PM, Russ Combs <rcombs () sourcefire com> wrote:
>
> > On Mon, Nov 8, 2010 at 1:55 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com
> > > wrote:
> >
> > > Hello.  I guess my questions now are:
> > >
> > > 1) is HTTP reassembly an officially recognised bug by SourceFire (I
> > > have gotten confirmation from multiple people on and off list that say
> > > they have similar issues)?
> >
> > As of now, "HTTP reassembly" is not an official bug.  I took the request
> > from the blog link, created what appeared to be an equivalent session (as
> > far as the request goes) and don't have any problem with reassembly.
> >
> > > and
> > >
> > > 2) When is it going to be fixed?  As previously mentioned, I consider
> > > this non-trivial since it leads to easy IDS/IPS evasion.
> > >
> > > That is not to say that you don't have a legitimate issue.  But a pcap
> > would certainly help validate the problem here and expedite the fix.
> >
> >
> > > Thanks.
> > >
> > > -L0rd C.
> > >
> > >
> > > On Mon, Nov 8, 2010 at 11:36 AM, Steven Sturges
> > > <steve.sturges () sourcefire com> wrote:
> > > > The issue I was referring to doesn't sound like Eoin's.
> > > >
> > > > It was something that was an issue in 2.9.0 with the addition
> > > > of some of the stateful tracking in HTTP response tracking
> > > > (partly in relating to gzip decoding and dechunking of responses)
> > > > when dealing with stream reassembled vs original data packets.
> > > > That was what I was indicating was addressed in 2.9.0.1.
> > > >
> > > > I apologize for the confusion here... Didn't realize that you
> > > > were specifically referring to the other post.
> > > >
> > > > Cheers.
> > > > -steve
> > > >
> > > > On 11/8/2010 12:11 PM, L0rd Ch0de1m0rt wrote:
> > > > > Hello.  Unfortunately I cannot provide pcap but I hoped to provide
> > > > > enough info so that it could be reproduced.
> > > > >
> > > > > Eoin:  I saw your email and read your blog post when it came out ... I
> > > > > was just hoping that snort version 2.9.0.1 fixed the issues with the
> > > > > HTTP pre-processor and reassembly since Steve Sturges indicated it did
> > > > > but maybe he is referring to other fixes???
> > > > >
> > > > > -L0rd C.
> > > > >
> > > > > On Mon, Nov 8, 2010 at 10:54 AM, Russ Combs <rcombs () sourcefire com>
> > > wrote:
> > > > > > Can you send us a pcap?
> > > > > >
> > > > > > On Mon, Nov 8, 2010 at 11:45 AM, L0rd Ch0de1m0rt <
> > > l0rdch0de1m0rt () gmail com>
> > > > > > wrote:
> > > > > > > Hello.
> > > > > > >
> > > > > > > I am still experiencing HTTP stream reassembly issues when trying to
> > > > > > > match across multiple fragmented packets with snort 2.9.0.1.
> > > > > > >
> > > > > > > Specifically, this happens on a HTTP POST where the headers are in a
> > > > > > > different packet than the POST data. Consider the following rule you
> > > > > > > can use along with scapy to reproduce if you want:
> > > > > > >
> > > > > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Incoming German
> > > POST
> > > > > > > to Batman"; flow:established,to_server; content:"POST"; http_method;
> > > > > > > uricontent:"/batcave/"; uricontent:"unicorns4sourcefire";
> > > content:"|0d
> > > > > > > 0a|Accept-Language: de"; nocase; http_header; content:!"|0d 0a 0d
> > > > > > > 0a|not4batman=true&"; content:!"\; batsecret=sesstoken4robin";
> > > > > > > http_cookie; classtype:trojan-activity; sid:8008135; rev:17;)
> > > > > > >
> > > > > > > It alerts (b/c all the URI and HTTP header stuffs match in the
> > > initial
> > > > > > > packet) but it shouldn't alert b/c the HTTP POST data starts with
> > > > > > > 'not4batman=true&' (but the POST data is in a subsequent packet than
> > > > > > > the one containing the headers).
> > > > > > >
> > > > > > > Anyone else still having issues or have done more in-depth testing
> > > > > > > with 2.9.0.1 and the HTTP pre-processor?
> > > > > > >
> > > > > > > -L0rd C.
> > > > > > >
> > > > > > > On Tue, Nov 2, 2010 at 5:34 PM, Steven Sturges
> > > > > > > <steve.sturges () sourcefire com> wrote:
> > > > > > > > There was an issue in that HTTP inspect wasn't correctly handling
> > > > > > > > raw vs. stream reassembled packets when looking at HTTP response
> > > > > > > > data.  This fix is included in 2901 -- refer to ChangeLog (changes
> > > > > > > > to hi_client.c/hi_server.c).
> > > > > > > >
> > > > > > > > As to the support of 2.8.6, with the release of 2.9.0, 2.8.6.x
> > > > > > > > is no longer supported.  When there is a new "3 digit" release no
> > > > > > > > further patches are made to the previous version of Snort.
> > > > > > > >
> > > > > > > > On 11/1/2010 1:05 PM, L0rd Ch0de1m0rt wrote:
> > > > > > > > > Hello. Does this release fix the issue where the HTTP
> > > pre-processor
> > > > > > > > > wasn't properly examining reassembled data across fragmented
> > > packets?
> > > > > > > > > (I don't know the exact cause of the bug - maybe it was the other
> > > way
> > > > > > > > > around and Stream5 wasn't properly doing the reassebly.)  It was
> > > > > > > > > announced that there would be a patch for that issue, just want to
> > > see
> > > > > > > > > if this is it.  If so, when can we expect the 2.8.6.1 patch be
> > > > > > > > > released?  2.8.6.1 is still supported, right?
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > -L0rd C.
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel