[28981] in bugtraq
RE: Bypassing Personal Firewalls
daemon@ATHENA.MIT.EDU (Drew Copley)
Fri Feb 21 19:19:15 2003
From: "Drew Copley" <dcopley@eeye.com>
To: "'Oliver Lavery'" <oliver.lavery@sympatico.ca>,
<bugtraq@securityfocus.com>
Date: Fri, 21 Feb 2003 15:31:30 -0800
Message-ID: <000301c2da01$5cc85310$3e01a8c0@eCompany.gov>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <005301c2da00$2c398ee0$0200a8c0@Oliver>
> -----Original Message-----
> From: Oliver Lavery [mailto:oliver.lavery@sympatico.ca]
> Sent: Friday, February 21, 2003 3:23 PM
> To: 'Drew Copley'; bugtraq@securityfocus.com
> 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
>
>
>
