[Snort-devel] Snort Now Available

L0rd Ch0de1m0rt l0rdch0de1m0rt at ...2499...
Mon Nov 8 13:55:49 EST 2010

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


2) When is it going to be fixed?  As previously mentioned, I consider
this non-trivial since it leads to easy IDS/IPS evasion.


-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
> 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 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 ...2840...9...>
>>> wrote:
>>>> Hello.
>>>> I am still experiencing HTTP stream reassembly issues when trying to
>>>> match across multiple fragmented packets with snort
>>>> 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 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 patch be
>>>>>> released? is still supported, right?
>>>>>> Thanks!
>>>>>> -L0rd C.

More information about the Snort-devel mailing list