Paul Montgumdrop said:
Anyone out there know about this?
<copied from a poster>
Even if it never happens, if there is two users logged in at the same
time, one is admin and has open a window, the other user can take
advantage of the open window that the admin uses and do everything an
admin would be able to do, as microsoft don't check from whom a command
comes, it just assumes that the user who uses the window is the one who
is logged into that session where it's displayed. There is a fix for
this, but requires a rewrite of explorer and make all GUI using
application to not work.
This is not quite as you describe.
1. First, let's state the obvious - if two people are physically using the
same computer, and one walks away without locking the session, or switching
it to the other user, yes, the user left in front of the keyboard can do
whatever he wants using the departed user's credentials, including setting
up a kind of 'back door' into the account.
2. Now, to the automated part of your discussion - if the two accounts are
in separate sessions - I.e. you have used the Switch User feature to keep
them separate, then no, there should be no way to have an unprivileged
program in the one session somehow break over to the other session and break
in to its administrative mode.
2a. If you are using 'runas', or 'run as administrator', or in some other
way running some processes as administrator, and other processes as a
restricted user, but both are running in the same session, on the same
desktop, there are almost certainly ways in which to have an unprivileged
program provide input to the privileged process, and perhaps interfere with
it more strongly.
The key is to consider what is meant by a "security boundary" - it's a line
that's drawn between two easily distinguishable partitions of the system's
operation, and it's a line that is guaranteed by the system's developer to
be a protected line over which all communication is carefully restricted so
as not to constitute a means to elevate or transfer privilege without having
the credentials required to do so.
A couple of keys here:
1. Easily distinguishable partitions - this comes from the concept of a
"line", as opposed to a "diffuse grey border". A line can be drawn between,
say, different sessions in an operating system, because it is clear which
session owns which piece of memory - but a line cannot be drawn between,
e.g., "code" and "data" (is a Javascript program "code" or "data"? It
depends.). Similarly, there is no sharp dividing line between two windows on
the same desktop - they share a communication to and from the desktop, and
sometimes between themselves. Because the operating system was not designed
to maintain separation between windows on a common desktop, this is not a
security boundary.
2. Guaranteed - there may be some apparent clear delineation between two
parts of a system, but unless the system's developers have guaranteed to
keep something as a security boundary, you cannot be sure that any effort
has gone into place to keep this delineation, or that the delineation is
anything other than your own hopeful delusion.
3. Elevate or transfer privilege without having the credentials to do so -
Obviously, the ability to switch to another session, enter the correct
password, and log on, requires that you know the correct password. Hence,
doing so is not considered an "elevation". To claim otherwise would be like
claiming that a lock is unsecure because "anyone with the right key can
unlock it". That is, of course, the function of the lock in a nutshell. It
is only when someone with the wrong key, or no key at all, can unlock it
that the lock is shown to be unsecure.
So, no, what the original poster describes is clearly _not_ the case - two
processes running in different sessions should not interfere, because there
is a security boundary between them. I'd say "cannot" instead of "should
not", except that bugs do happen - but because this is a security boundary,
if a means to cross that security boundary is found, that will be considered
a bug that needs immediate fixing.
Alun.
~~~~
