[Snort-devel] Snort 2.9.0.1 Now Available

Russ Combs rcombs at ...402...
Tue Nov 9 15:52:52 EST 2010


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 at ...402...> 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 at ...2780...  Please copy
> snort-team at ...402... and/or snort-devel at 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 at ...2780... 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 at ...3055...> <eoin.miller at ...3055...>  To:
> research at ...402...
>
> 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 at ...402...> wrote:
>
>>
>>
>> On Mon, Nov 8, 2010 at 1:55 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt at ...2499...
>> > 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 at ...402...> 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 at ...402...>
>>> wrote:
>>> >>> Can you send us a pcap?
>>> >>>
>>> >>> On Mon, Nov 8, 2010 at 11:45 AM, L0rd Ch0de1m0rt <
>>> l0rdch0de1m0rt at ...2499...>
>>> >>> 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 at ...402...> 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.
>>> >>>>>>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20101109/05e05335/attachment.html>


More information about the Snort-devel mailing list