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

Martin Roesch roesch at ...402...
Mon Jan 5 16:29:21 EST 2009


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


More information about the Snort-devel mailing list