[Snort-devel] Patch for snort 2.8.3.1 - Decompressing Gziped HTTP responses

Breno Silva breno.silva at ...2499...
Mon Jan 5 20:22:02 EST 2009


Hi Martin,

I finished the new code. I will test it tomorrow in my network and send you
as soon as possible.

Cheers

Breno

On Mon, Jan 5, 2009 at 7:43 PM, Breno Silva <breno.silva at ...2499...> wrote:

> Hi Martin,
>
> Thanks for all the suggestions. I will work as soon as possible in the code
> and fix it.
>
> I´ll send you back soon!
>
> Regards,
>
> Breno
>
> On Mon, Jan 5, 2009 at 7:29 PM, Martin Roesch <roesch at ...402...>wrote:
>
>> Hi Breno,
>>
>> This is really cool, thanks for sending it in.  I have some comments.
>>
>> 1) I'd remove the inline assembler code in parse_http().  It hinders
>> portability (this code will need to run on more than x86) and is far less
>> readable than C code.  I understand it's AT&T asm but since it looks like
>> you're doing pretty simple pattern matching/protocol parsing it'd be pretty
>> easy to just write a state machine in C to look for the data.  If you're
>> trying to write portable asm that's pretty much what C is for! :)
>>
>> 2) I'd calloc() the decompressed_data buffer instead of malloc + memset.
>> Less code = fewer opportunities for bugs. :)
>>
>> 3) Your rebuild_packet() function seems to be effectively executing a
>> memcpy(), why not just do that?  I see that you're allocating Packet * 2
>> bytes there but I think you should be allocating sizeof(Packet) +  (p->dsize
>> * 2) if I'm reading this right.  Additionally, if the allocated buffer size
>> is greater than 64k you should cap it, Snort's packet-based analysis engines
>> may have trouble with packets larger than the 64k max.  You can experiment
>> to see if that's true or not. :)  You might want to also think about
>> preallocating the pp object since you don't really want to be
>> malloc/free-ing for every packet that your system gets, memory is
>> (relatively) cheap!
>>
>> 4) In your match() function, you should preallocate/precompile your
>> pattern match machines at startup time (once) and then reference them.
>> Additionally, you should really be using the Boyer-Moore pattern matcher
>> available in Snort since you're looking for static patterns anyway.  You
>> definitely shouldn't be running a pattern compile for each packet you send
>> through your code though unless the patterns change at runtime.
>>
>> Generally speaking, you've got a few memset()'s and memcpy()'s in there
>> which are somewhat time intensive, I'd see if you can refactor things to
>> reduce the number of those you have if possible.
>>
>> Great work though, I'll be interested to see where you take it!
>>
>> Marty
>>
>>
>>
>> 2008/12/25 Breno Silva <breno.silva at ...2499...>
>>
>>>   Snort community,
>>>
>>>
>>> I finished my patch for snort 2.8.3.1 that will decompress HTTP gziped
>>> responses. It will help us to detect HTTP client side exploits inside gziped
>>> connections.
>>> I patched my snort sensors and it is working well at this moment. Hope we
>>> have help you to have this feature in the future.
>>> I sent it for SourceFire VTR ( Alex and Matthew ), and probably snort
>>> core team already have this patch. I´m posting it here now for all the snort
>>> developers.
>>>
>>> I´m suggesting the following modifications:
>>> - http_uncompress_gzip.h  :  here we have almost all functions to
>>> decompress gziped http packets
>>> - snort_httpinspect.diff : our main code
>>> - spp_httpinspect.diff and hi_include : we added gzip stats
>>>
>>> I tested the code exploiting a Windows box downloading a milw0rm client
>>> side exploit :
>>>
>>>   http://www.milw0rm.com/exploits/7477
>>>
>>> The VRT rule (15126: rev 3) now works well against this kind of
>>> connection:
>>>
>>> Dec 23 14:41:35 estreamerAgent snort: [1:15126:3] WEB-CLIENT Internet
>>> Explorer nested span tag memory corruption attempt [Classification:
>>> Attempted User Privilege Gain] [Priority: 1]: {TCP} 76.74.9.18:80<http://76.74.9.18/>-> xxx.61.154.128:1263
>>>
>>> And we check  for gziped stats:
>>>
>>> TTP Inspect - encodings (Note: stream-reassembled packets included):
>>>     POST methods:                   0
>>>     GET methods:                    2
>>>     Headers extracted:              2
>>>     Header Cookies extracted:       0
>>>     Post parameters extracted:      0
>>>     Unicode:                        0
>>> *    Gziped Packets:                 1   *
>>>     Double unicode:                 0
>>>     Non-ASCII representable:        0
>>>     Base 36:                        0
>>>     Directory traversals:           0
>>>     Extra slashes ("//"):           0
>>>     Self-referencing paths ("./"):  0
>>>     Total packets processed:        3
>>> PS: Link with zlib to make it work.
>>>
>>> Cheers,
>>>
>>> Breno Silva
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Snort-devel mailing list
>>> Snort-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>>>
>>>
>>
>>
>> --
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>> Snort: Open Source IDP - http://www.snort.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20090105/07a98ab4/attachment.html>


More information about the Snort-devel mailing list