Hi Martin,<br><br>I finished the new code. I will test it tomorrow in my network and send you as soon as possible.<br><br>Cheers<br><br>Breno<br><br><div class="gmail_quote">On Mon, Jan 5, 2009 at 7:43 PM, Breno Silva <span dir="ltr"><<a href="mailto:breno.silva@...2499...">breno.silva@...2997...499...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Hi Martin,</div>
<div> </div>
<div>Thanks for all the suggestions. I will work as soon as possible in the code and fix it.</div>
<div> </div>
<div>Ill send you back soon!</div>
<div> </div>
<div>Regards,</div>
<div> </div><font color="#888888">
<div>Breno<br><br></div></font><div><div></div><div class="Wj3C7c">
<div class="gmail_quote">On Mon, Jan 5, 2009 at 7:29 PM, Martin Roesch <span dir="ltr"><<a href="mailto:roesch@...402..." target="_blank">roesch@...402...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Hi Breno,<br><br>This is really cool, thanks for sending it in.  I have some comments.<br><br>
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! :)<br>

<br>2) I'd calloc() the decompressed_data buffer instead of malloc + memset.  Less code = fewer opportunities for bugs. :)<br><br>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!<br>

<br>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.<br>

<br>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.<br><br>

Great work though, I'll be interested to see where you take it!<br><br>Marty<br><br><br><br>
<div class="gmail_quote">2008/12/25 Breno Silva <span dir="ltr"><<a href="mailto:breno.silva@...2499..." target="_blank">breno.silva@...2840...9...</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div></div>
<div>
<div>Snort community,</div>
<div> </div>
<div> </div>
<div>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. <br><font size="2" face="sans-serif">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.</font> </div>


<div>I sent it for SourceFire VTR ( Alex and Matthew ), and probably snort core team already have this patch. Im posting it here now for all the snort developers.<br><br><font size="2" face="sans-serif">Im suggesting the following modifications:</font> <br>

<font size="2" face="sans-serif">- http_uncompress_gzip.h  :  here we have almost all functions to decompress gziped http packets</font> <br><font size="2" face="sans-serif">- snort_httpinspect.diff : our main code</font> <br>

<font size="2" face="sans-serif">- spp_httpinspect.diff and hi_include : we added gzip stats </font><br><br><font size="2" face="sans-serif">I tested the code exploiting a Windows box downloading a milw0rm client side exploit :</font> <br>

</div>
<div>
<table>
<tbody>
<tr>
<td><font size="1"><br></font>
<table width="100%">
<tbody>
<tr>
<td width="100%"><font size="3"><a href="http://www.milw0rm.com/exploits/7477" target="_blank">http://www.milw0rm.com/exploits/7477</a></font> <br><br><font size="3">The VRT rule (15126: rev 3) now works well against this kind of connection:</font> <br>

<br><font size="3">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} <a href="http://76.74.9.18/" target="_blank">76.74.9.18:80</a> -> xxx.61.154.128:1263</font> <br>

<br><font size="3">And we check  for gziped stats:</font> <br><br><font size="3">TTP Inspect - encodings (Note: stream-reassembled packets included):</font> <br><font size="3">    POST methods:                   0         </font><br>

<font size="3">    GET methods:                    2         </font><br><font size="3">    Headers extracted:              2         </font><br><font size="3">    Header Cookies extracted:       0         </font><br><font size="3">    Post parameters extracted:      0         </font><br>

<font size="3">    Unicode:                        0         </font><br><font size="3"><b>    Gziped Packets:                 1   </b>      </font><br><font size="3">    Double unicode:                 0         </font><br>

<font size="3">    Non-ASCII representable:        0         </font><br><font size="3">    Base 36:                        0         </font><br><font size="3">    Directory traversals:           0         </font><br><font size="3">    Extra slashes ("//"):           0         </font><br>

<font size="3">    Self-referencing paths ("./"):  0         </font><br><font size="3">    Total packets processed:        3         </font><br></td></tr></tbody></table></td></tr></tbody></table></div>
<div>PS: Link with zlib to make it work.</div>
<div> </div>
<div>Cheers,</div>
<div> </div><font color="#888888">
<div>Breno Silva</div></font><br></div></div>------------------------------------------------------------------------------<br><br>_______________________________________________<br>Snort-devel mailing list<br><a href="mailto:Snort-devel@lists.sourceforge.net" target="_blank">Snort-devel@...2968...ourceforge.net</a><br>

<a href="https://lists.sourceforge.net/lists/listinfo/snort-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-devel</a><br><br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>

Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616<br>Sourcefire - Security for the Real World - <a href="http://www.sourcefire.com/" target="_blank">http://www.sourcefire.com</a><br>Snort: Open Source IDP - <a href="http://www.snort.org/" target="_blank">http://www.snort.org</a><br>

</font></blockquote></div><br>
</div></div></blockquote></div><br>