Re: msg update for these, please?

[waldo kitty <wkitty42 () windstream net>]

On 9/28/2010 16:11, Alex Kirk wrote:
> On Tue, Sep 28, 2010 at 3:55 PM, waldo kitty <wkitty42 () windstream net> wrote:
>
>     ahhh... my bad... i didn't/don't see a content:"GET "; depth:4; in there... i
>     assume a GET is determined because it is http_uri?
>
> Actually, any method that has a ".exe" in the URI will fire on this. 99.99% of
> the time that means GET.

that's what i thought as i've been looking at that rule... it could stand to 
have some work done to it to avoid those FPs if it is meant to detect HTTP GET 
requests for any .exe files since that appears to be its intended task ;)

> >    (yes, i realize that the content i just used up there is "old style" but it is
> >    extremely clear in its intent ;) )
>
> >    how would that rule appear if it were an actual executable upload to the
> >    "server"? i assume that would be a POST...
>
> The URI would likely have nothing to do with a client uploading an executable to
> a web server - it'd be in the POST data of a page that could have an arbitrary
> URL (for example, you can POST an .exe up to a webmail system, whose URI might
> look like "https://mail.google.com/mail/?hl=en&shva=1#inbox

true... i guess i'm being too strict in my analysis ;)
but then again, i was also thinking about the transmission of the file's name...

>     that also means that my original post should have read like this...
>
>     OLD:
>       15306   WEB-CLIENT Portable Executable binary file transfer
>       16425   WEB-CLIENT Portable Executable binary file transfer
>
>     NEW:
>       15306   WEB-CLIENT Portable Executable binary file transfer
>       16425   WEB-CLIENT Executable binary file request
>
>     OR:
>       15306   WEB-CLIENT Portable Executable binary file transfer to client
>       16425   WEB-CLIENT Executable binary file request to server
>
> See my reply to Shawn.

i saw it... i expect that you've seen my response as well ;)

>     this because .exe does not denote a PE .exe binary by default ;)
>
> As a file extension it sure does.

you should have seen my private response to this part by now... to clarify, the 
following .exe files are NOT Portable Executable files but they all have the 
".exe" extension...

   DOS 16-bit
   DOS 32-bit (requires an extender)
   OS2 16-bit
   OS2 32-bit

i'm fairly sure there are still others out there, as well...

this is also why my comments above specifically leave the word "Portable" out of 
my suggested options ;)

>     i wonder what a GET /foo/my.exe.sourcecode.pas would do with that rule? :P
>
> Honestly, it'd generate a FP. There's a feature request in to allow us to pin a
> content to the end of a buffer (including, I believe, the end of a URI before
> the parameters start) that should fix that.

it might... at least as far as detecting a request for something ending in 
".exe" which may or may not be a Portable Executable... of course, it will also 
fail if URLs similar to VRT's current snort rules snapshots use

   ie: /foo/my.exe?id=somerandomnumber

in any case, i want to thank you for taking the time to acknowledge my request 
and do something to correct the situation... thank you :)

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users