Inter-process communication

[sec_ware]

Hi

There are many forms of inter-process communications[1],
certainly TCP/IP is often used, but also [D]COM or named
pipes[2] are common. The goal of IPC actually is to provide
some kind service to to other processes regardless
of their owner (this would be part of the service-implementation
itself) or even machine.

Mailslots and pipes are accesses with file operations. If IPC$
is accessible from other machines, you can even access an IPC$-IPC
service from remote (not routed though).


Restrictions are given sometimes by the operating system. For
example, on most *nix-derivates, as most of you konw, ordinary users
can only bind ports larger 1024.

For a more theoretical white paper on IPC in gerenal (threading,
thread models etc.) read [3].


So, in summary, FOO can "write" to BAR and BAR can "write" to FOO
because the process BAR that supports IPC is supposed to enable FOO
to interact, as said, in principle regardless of the users ACLs and privileges.
That's why it may be dangerous to have a process BAR started in the
context of an administrator account providing IPC access - a vulnerability
could be exploited to run arbitrary code in the context of an administrator
account.



Cheers.



[1] http://msdn2.microsoft.com/en-us/library/aa365574.aspx
[2] http://support.microsoft.com/kb/871044/en-us
[3] http://research.microsoft.com/users/...terprocess.pdf