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

Breno Silva breno.silva at ...2499...
Tue Jan 6 11:16:54 EST 2009


Hi Martin,

I'm sending the new code with some changes. Please feel free to comment or
to change something you want and send me back for tests if necessary.

I think it could be a first code for snort and we can add more features in a
near future!

Regards,

Breno

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

> 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/20090106/0ca9df3b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpinspect_gzip_patch-snort_2.8.3.1-2.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20090106/0ca9df3b/attachment.tar>


More information about the Snort-devel mailing list