> -----Original Message-----
> From: xenophi1e [mailto:oliver.lavery (at) sympatico (dot) ca [email concealed]]
> Sent: Friday, February 21, 2003 1:34 PM
> To: bugtraq (at) securityfocus (dot) com [email concealed]
> Subject: Bypassing Personal Firewalls
>
>
<snip>

> Here's a code snippet that injects code directly into a
> running process
>
> without the need for a DLL etc. I believe that it demonstrates that
>
> process boundaries under NT mean very little within the context of a
>
> given UID.

<snip>

> I think it
> illustrates
>
> that OpenProcess, ptrace, and the like should really enforce
> filesystem
>
> priviledges on the processes they can modify. I think that this is
>
> something that needs to be done proactively.
>
>
>
> The implication of allowing processes to modify each other
> this way is
>
> that PFWs can not be easily made secure, but also that
> malicious code has
>
> nice support from windows for doing some very bad things. For
> instance it
>
> would be a simple addition to intercept syscalls made by any
> process into
>
> which code can be injected, and in so doing hide the presence of
>
> malicious activity from all local processes a user runs.
<snip>

(Sidenote: a number of previous apps used to test PFWs or Application
Firewalls --
http://www.pcflank.com/art21.htm )

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

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.

After that, you are probably talking about having to do somesort of
signature analysis at the binary level.

It is always an arms race.

OpenProcess does require seDebugPrivileges, I believe.

[An interesting "arms race" to follow in this regards is between GearBox
software and HL cheaters, btw.]

Drew

Research Engineer
eEye Digital Security

[ reply ]