> -----Original Message-----
> From: Oliver Lavery [mailto:oliver.lavery (at) sympatico (dot) ca [email concealed]]
> Sent: Friday, February 21, 2003 3:23 PM
> To: 'Drew Copley'; bugtraq (at) securityfocus (dot) com [email concealed]
> Subject: RE: Bypassing Personal Firewalls
>
>
> >(Sidenote: a number of previous apps used to test PFWs or Application
> Firewalls --
> >http://www.pcflank.com/art21.htm )
>
> Yes, these are great tests. Most PFWs block them all now.

I believe TooLeaky and Firehole remain unfixed on some firewalls.

Too leaky apparently just runs IE with a url cmd argument.

Firewall uses the messy way of hooking: SetWindowsHookEx

>
> >There are a number of ways to do this, you use the more
> popular method
> >of
> openprocess and
> >writeprocess memory. However, there is a limit to the number of api
> >calls
> which implement this.
> >Ultimately, this kind of code needs to be blocked, first, at
> the NT API
> level... Such blocking
> >should use the same method as blocking the network calls,
> ie, "Do you
> >want
> to allow this
> >application to ..."
>
> Yes. Before we go prompting users ever time someone
> calls CreateFile, though, there are much simpler measures.
> One of them would make OpenProcess require a priviledge of
> some sort (see below).
>
> >Most commonly, this would be used with writeprocess memory.
> >Createremotethread would need to be blocked in this manner.
> Postremotethreadmessage.
> >PostThreadMessage. Are some of the more dangerous calls, in this
> >context.
>
> You'll notice that all of these calls require a handle
> returned by OpenProcess (hProcess in my code).
>
> >After that, you are probably talking about having to do somesort of
> signature analysis at the
> >binary level.
>
> MD5 of the binary memory image! This is probably
> feasible, but good god it would resource intensive.

Any such method remains limited. You are in the openrange here.

Here is a relevant and interesting paper:

http://www.cs.washington.edu/homes/saurabh/papers/oh.pdf

"Abstract. We describe a novel software verification primitive called
Oblivious Hashing. Unlike previous techniques that mainly verify the
static shape of code, this primitive allows implicit computation of a
hash value based on the actual execution (i.e., space-time history of
computation) of the code. We also describe its applications in local
software tamper resistance and remote code authentication."

>
> >OpenProcess does require seDebugPrivileges, I believe.
>
> No, and this is very much the point. According to MS docs:
> SeDebugPrivilege:
> Determines which users can attach a debugger to any process.
> This privilege provides powerful access to sensitive and
> critical operating system components.
>
> This only prevents users from using OpenProcess on
> system processes (winlogon.exe etc.). There need to be
> tighter restrictions on the use of OpenProcess.

Ah, that's right, remember now.

>
> Cheers,
> ~ol
>
>
>

[ reply ]