-
December 29th, 2007, 07:49 PM
#1
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
"Personality is only ripe when a man has made the truth his own."
-- Søren Kierkegaard
-
December 29th, 2007, 08:10 PM
#2
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
-
December 30th, 2007, 03:13 PM
#3
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
Last edited by sec_ware; December 30th, 2007 at 03:16 PM.
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)
-
December 30th, 2007, 06:56 PM
#4
That's just the sort of information I was looking for, sec_ware! Thanks!
- X
"Personality is only ripe when a man has made the truth his own."
-- Søren Kierkegaard
Similar Threads
-
By cheyenne1212 in forum Miscellaneous Security Discussions
Replies: 7
Last Post: February 1st, 2012, 02:51 PM
-
By earthrocker in forum Newbie Security Questions
Replies: 7
Last Post: August 5th, 2006, 03:43 PM
-
By Egaladeist in forum Spyware / Adware
Replies: 21
Last Post: April 15th, 2005, 11:30 PM
-
By gore in forum Operating Systems
Replies: 3
Last Post: March 7th, 2004, 08:02 AM
-
Replies: 1
Last Post: July 15th, 2002, 03:46 AM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|