COMMAND
RunAs...
SYSTEMS AFFECTED
Win2k
PROBLEM
Jesper M. Johansson found following:
1. Log on as a regular user. Make sure that this users security
zones are set such that most things are disabled, such as
Active Scripting.
2. Click Start, then right-click on Windows Update and select Run
As...
3. Run Windows Update as an administrator. Make sure that most
things, such as Active Scripting, is enabled for this user
4. Leave the IE window open.
5. Now open Outlook, or any other program that understands
hyperlinks, as the regular user
6. Click on a hyperlink. The OS will send the hyperlink to the
instance of IE that is running under that Admin account if that
is the only open instance of IE
This seems like a bug. That instance of IE is running under the
Administrative users context. How is it that a program in a
regular user context is able to communicate with it? If you
instead try to open a favorite from the start menu, or a link
from the Links portion of the task bar, the correct behavior,
namely opening a new instance of IE, occurs.
SOLUTION
One workaround for Administrators who have a lower privileged user
context for normal logons and use the "Run As" feature for
specific tasks, put IE into your Startup folder and have it
launched (minimized) as soon as you logon. This will ensure that
the first instance of IE on your box is a non-privileged instance,
and any instances caused by clicking on links should draw their
environment from that instance.
RunAs creates a separate logon session for the target user
principal, loads that user's profile, and executes the process in
that new environment. The one difference is that when run from
the interactive window station, the new process also lives in
the interactive window station, which is not the natural state of
affairs. Normally each logon session has its own distinct window
station to host processes. This is to keep processes in one logon
session from sending window messages to processes in other logon
sessions (which would allow one logon session to hijack another).
Normally daemon processes that are started (by the SCM, say)
running in alternate logon sessions are housed in distinct window
stations so that they cannot do stuff like the following
psuedo-code:
SendKeys "<ctrl-esc> r format c:\ <enter>"
causing Explorer to do bad things on behalf of the interactive
user. Because RunAs (when executed by the interactive user)
causes the new process to live in the same window station, you
really don't have a sandbox at all. Now, be aware that RunAs
puts the new process into a job, and it's possible to blind all
processes in a job from windows created by processes outside of
that job (not yet verified that this protection is in effect).
AFAIK this particular job is simply used for notification when all
processes in the logon session have terminated so that the RunAs
daemon can unload the profile. Even if this attribute on the job
were to be set, it wouldn't keep processes in the interactive
logon session from sending window messages *into* processes
sandboxed by the job, so there's no clear isolation as there is
when processes run in separate window stations.
The expected use of RunAs is to start a process interactively with
*elevated* privileges, not with lessened privileges. You should
not think of it as creating a sandbox. On the other hand, running
a *service* as a distinguished principal does create a true
sandbox (except for the bug described earlier with regards to
window station security not being enforced during CreateProcess;
but this bug is being fixed). This explaniation was taken by
Keith Brown.