Inter-process communication

Suppose I have two users accounts on a Windows XP Professional machine: user X and Y. Suppose also that both of these accounts are members of the Restricted Users group (instead of being members of the Administrators/Power Users groups).

Suppose user X is interactively logged in and he runs process FOO under his credentials. Assume also that he runs process BAR under Y's credentials (with, for example, the command: runas /user:computername\Y BAR.exe).

Here's the question: can process FOO (started by user X and running as X) communicate with process BAR (started by X but running as user Y) with any sort of inter-process communication? Can BAR communicate with FOO?

If yes, under what circumstances and how? I would assume that because user X has no read permissions over Y's directory (and vice versa), that X's processes would not be able to communicate with Y's processes, but I'm suspicious that it may be otherwise.

- Xierox

Hi there xierox,

I believe that there is a way in XP Professional to get people to actually share the machine and whatever systems you want them to.

It has been a while since I have done it, so I would have to check that out.

If I remember correctly, it should do exactly what you want. The issue I mostly encountered was people getting elevated privileges because they could log in whilst the more senior user still had their account open on the shared machine?

I will check it out and get back, if there isn't someone here with a better memory than mine :D

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

That's just the sort of information I was looking for, sec_ware! Thanks!

- X