Snort mailing list archives
Re: Snort 2.9.0.1 Now Available
From: Russ Combs <rcombs () sourcefire com>
Date: Tue, 9 Nov 2010 15:52:52 -0500
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 comwrote: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 pcapwould 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 GermanPOSTto Batman"; flow:established,to_server; content:"POST"; http_method; uricontent:"/batcave/"; uricontent:"unicorns4sourcefire";content:"|0d0a|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 theinitialpacket) 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 HTTPpre-processorwasn't properly examining reassembled data across fragmentedpackets?(I don't know the exact cause of the bug - maybe it was the otherwayaround and Stream5 wasn't properly doing the reassebly.) It was announced that there would be a patch for that issue, just want toseeif 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
Current thread:
- Re: [Emerging-Sigs] [Snort-devel] Snort 2.9.0.1 Now Available, (continued)
- Re: [Emerging-Sigs] [Snort-devel] Snort 2.9.0.1 Now Available Miso Patel (Nov 03)
- Re: [Emerging-Sigs] [Snort-devel] Snort 2.9.0.1 Now Available Matthew Jonkman (Nov 03)
- Re: Snort 2.9.0.1 Now Available Randal T. Rioux (Nov 03)
- Re: Snort 2.9.0.1 Now Available L0rd Ch0de1m0rt (Nov 08)
- Re: Snort 2.9.0.1 Now Available Russ Combs (Nov 08)
- Re: Snort 2.9.0.1 Now Available L0rd Ch0de1m0rt (Nov 08)
- Re: Snort 2.9.0.1 Now Available Steven Sturges (Nov 08)
- Re: Snort 2.9.0.1 Now Available L0rd Ch0de1m0rt (Nov 08)
- Re: Snort 2.9.0.1 Now Available Russ Combs (Nov 08)
- Re: Snort 2.9.0.1 Now Available Russ Combs (Nov 09)
- Re: Snort 2.9.0.1 Now Available Russ Combs (Nov 09)
- Re: Snort 2.9.0.1 Now Available Eoin Miller (Nov 08)
- Re: Snort 2.9.0.1 Now Available Eoin Miller (Nov 08)
- Re: Snort 2.9.0.1 Now Available Mike Lococo (Nov 01)
- Re: Snort 2.9.0.1 Now Available Jason Haar (Nov 02)
- Re: Snort 2.9.0.1 Now Available Mike Lococo (Nov 02)
- Re: Snort 2.9.0.1 Now Available Mike Lococo (Nov 02)