"run as" local denial-of-service enables administrative account processes to be killed Jun 23 2007 08:44PM
Eitan Caspi (eitancaspi yahoo com) (1 replies)
Suggested severity level: Medium.

Type of Risk: Denial of Service.

Local / Remote activated: Local.

Affected Software: Windows XP Professional with SP2
and all of the security
updates up to 5-May-2007.
Windows 2003 standard server, revision R2 was tested
also a found to be NOT
Window Vista was not tested due to lack of resources.

Summary: While a user, at any security membership
level, is logged in
locally, using the "run as" feature, it can kill all
of the processes
running under the user who initiated the "run as"
feature, even if the
initiating user has a security membership level higher
than the user
initiating the killing action under "run as". The kill
is performed using
the taskkill.exe application which is built into
Windows XP.

General Notes:
1. This issue is, of course, mostly relevant to be
exploited while running
using a malicious binary file and less in an
interactive way by a local user
(like in a Kiosk / full-screen scenarios).
This advisory is using the interactive method for
demonstration purposes.
2. I will refer to the user initiated the "run as"
feature as the "host" and
to the user being run "inside" "run as" as the
3. This can be done when either using the terminal
based "Fast User
Switching" ((FUS), regardless if it is the console or
terminal based) or the
regular local console (only one user can be logged-in
locally at a time).
4. A contributing factor to the success of the attack
is that any user with
a "users" group membership only, can view a list of
processes being
currently run by other users (although it is NOT
possible using the regular
"Task Manager") using the built-in utility
tasklist.exe ("tasklist /v" adds
the user name attached to each process, and then "
tasklist /fi "username eq
computer_name\user_name" " to filter out the processes
of a specific user)
and an MS utility like "process explorer".
5. This vulner is active only with the combination of
"run as" and
"taskkill". Regular usage of taskkill will not allow
the attack (an "access
is denied" error message will appear).
6. The guest can kill process of the host, regardless
of the host's security
membership level - be it identical to the guest or
7. Using the older version of taskkill, tskill.exe,
was not successful and
the attack failed under the same conditions.
8. While using FUS - only the host user's processes
can be killed, not
process of the any other currently logged-in FUS
9. One factor that limits possible attack vectors is
that "run as" can't be
fully automated, since the password can't be stored in
advance and it must
be typed in with every activation of the command.
This can be defeated if one finds a way to store the
password within a
script or binary and activate the password input
during run-time.
10. One factor that empowers the possible success of
this attack is that
taskkill.exe is located under c:\windows\system32
which is included in the
"path" environment variable, thus allowing the
execution of this utility
regardless of the current path of the attacker in the
file structure of the
11. The attack was successful if the "run as" command
was started either by
the GUI or from a command line.

Possible Abuses: Any user that will use "run as", as a
kind of a "sandbox"
for running suspicious binaries or accessing the
internet, believing it will
defend him/her by using another user's identity, most
likely one with lower
security rights and permissions, will be exposed to a
denial of service
attack that can kill any of its running applications
and processes, up to
its entire logon sessions (explorer.exe) which will
prompt him/her to
shutdown the computer (which can happen if the user
will not be careful).

Preliminary steps:
1. Log in to the computer as a local administrator.
2. Create a user that is a member of only the local
"users" group.
3. I am not sure if the following step is needed - log
off, log in as the
regular user, to create its profile, then log off and
login again as the

Actual steps:
1. Create a desktop shortcut for cmd.exe
2. Run internet explorer (it will be used to be killed
3. Right mouse click the cmd.exe shortcut and choose
"run as".
4. Select the option "the following user" and enter
the regular user's name
and password and click "OK".
5. run the following command to list all of the
current running processes
with their relevant owner accounts:
tasklist /v /fo list
6. After spotting the desired user, administrator in
our case, run the
following command to filter only the processes run by
this user:
tasklist /fi "username eq administrator"
7. To kill a specific process you can kill it either
by process id (PID) or
by process/image name:
taskkill /pid number_of_desired_pid
taskkill /im iexplore.exe
Notice that "internet explorer" is gone now (from both
the GUI and the list
of running processes).
8. Run, as the host, the administrator user, internet
explorer again and
also run calculator (calc.exe) as well.
9. Now, we will run the following command to kill ALL
of the administrator
taskkill /fi "username eq administrator"
10. You can notice the following things happen:
A. The cmd window lists all of the administrator
process that was killed,
listed by their PID.
B. The internet explorer and calculator are killed.
C. Due to the killing of explorer.exe - the
logoff/restart/shutdown window
is presented. If the OS is using the "welcome screen"
the "stand by" option
is the default. If the OS is using the regular
console, "shut down" is the
default option, and careless user can shut down the

Exploit Code: No need.

Direct resolution: Not any that I am aware of at the
time of writing this

Workarounds: Not any that I am aware of at the time of
writing this

Vendor response: Microsoft was notified at the begging
of June 2007. I
really liked their answer:
RunAs and UAC are convenience features, not security
boundaries. If you need
a security guarantee, please log out and log back in
with a different
(When approaching the MS I mentioned UAC (User Account
Control), which is
used in Vista, as an opposite way (regarding "run as")
to limit the risk(

On the other hand, in a technical article by
Microsoft, titled "Secondary
Logon (Run As): Starting Programs and Tools in Local
Administrative Context"
(http://support.microsoft.com/kb/225035) it is
Secondary logons address the security problems
presented by administrators
running programs that may be susceptible to "Trojan
Horse" attacks (such as
running Microsoft Internet Explorer in the
administrative context while
accessing a non-trusted Web site).
Why make a feature and then ask users not to trust it?
I'm confused.

Eitan Caspi
Email: eitancaspi (at) yahoo (dot) com [email concealed]

Past security advisories:











You can find several articles I have written
(translated to English) at
(Filter: Author = Eitan Caspi (second names set), From
year = 2000 , Until
year = 2002)

Eitan Caspi

Current Blog (Hebrew):
Past Blog (Hebrew): http://www.notes.co.il/eitan
Dead Blog (English): http://eitancaspi.blogspot.com

"Technology is like sex. No hands on - No fun." (Eitan

Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.

[ reply ]
RE: "run as" local denial-of-service enables administrative account processes to be killed Jun 26 2007 02:30PM
James C. Slora Jr. (james slora phra com)


Privacy Statement
Copyright 2010, SecurityFocus