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

Breno Silva breno.silva at ...2499...
Mon Jan 5 16:43:39 EST 2009


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/de9318b9/attachment.html>


More information about the Snort-devel mailing list